fix(2.10.1): CaseMemory Controller + correct layout path

Two UI-breaking issues discovered after 2.10.0 hot-patch:

* Hitting /#CaseMemory in the navbar returned a 404 because CaseMemory
  was missing a Controller class. The entity used to be accessed only
  through Case relation panels and SmartAssistant action endpoints, so
  the bare REST surface was never wired. Same one-liner fix pattern as
  the AssistantRule controller in 2.9.2.

* Layouts were placed under Resources/metadata/layouts/... but EspoCRM
  expects them at Resources/layouts/... (without the metadata/ prefix).
  Result: every new entity rendered only one column / one row in list
  views because EspoCRM fell back to a generic default layout. Moved
  AssistantPrompt, AssistantRule, AssistantSkill, CaseMemory, UserProfile
  layouts to the canonical path. Verified all five list endpoints now
  serve the configured columns.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

files/custom/Espo/Modules/SmartAssistant/Controllers/CaseMemory.php

@@ -0,0 +1,17 @@
+<?php
+
+namespace Espo\Modules\SmartAssistant\Controllers;
+
+/**
+ * Standard CRUD over /api/v1/CaseMemory.
+ *
+ * Until SmartAssistant 2.10.0 the CaseMemory entity was created via
+ * CaseMemoryService::createMemory and listed via Case relation panels —
+ * never via the bare REST endpoint. Flipping `tab: true` exposes the
+ * navbar list view, which uses GET /api/v1/CaseMemory and needs this
+ * Controller class to exist (otherwise EspoCRM returns 404 "Controller
+ * does not exist"). Same pattern as the AssistantRule fix shipped in 2.9.2.
+ */
+class CaseMemory extends \Espo\Core\Controllers\Record
+{
+}