feat(config): default to no short-term or semantic memory, and infer the backend - #1580

…tup (speedkick)

`semantic_memory.enabled: false` only skipped the semantic service in
start(). Every request path that could name the semantic type still
resolved the semantic stack lazily and used it: add_episodes, query_search
and list_search branched on target_memories alone, and the SemanticManager
getters built storage, config store, embedder and language model on first
use without reading the flag (running Alembic migrations on the request
path for pgvector). The flag changed who paid to bring the stack up, not
whether it came up. With a complete config the request succeeded and did
real work; with the incomplete config that MemMachine#1580 now produces by default,
get_semantic_storage raised from inside the request.

Deletion had the same gap with a twist. memmachine.py defined
_cleanup_semantic_history twice; both arrived in MemMachine#1151. The later
definition, which requests the semantic service unconditionally, shadowed
the earlier one that caught ResourceNotReadyError, so with semantic memory
disabled every project deletion raised in the worker, dropped the job, and
left the session in `delete` status for good (MemMachine#1575). delete_episodes
requested the service unconditionally too.

Three changes:

- ResourceManagerImpl.get_semantic_manager raises
  ResourceNotReadyError("Semantic memory is disabled.") when the flag is
  off, so nothing semantic is constructed; get_semantic_service and
  get_semantic_session_manager go through it. The flag is read only on the
  server side: MemMachine routes requests, and the composition root refuses
  to build a component the deployment does not have. SemanticResourceManager
  and everything below it never see it. The semantic-only MemMachine
  operations (features, set types, ...) now fail with that message instead
  of building a stack the operator turned off.

- MemMachine gains enabled_memory_types, read from the two configuration
  flags, and add_episodes, query_search and list_search filter
  target_memories through it. A request naming a disabled type gets None
  for that field, exactly as when it did not name the type. Skipping
  rather than rejecting is forced by the client: memmachine_client sends
  both types on every add and search, so rejecting would fail every client
  call against the default configuration. Episodic gets the same
  treatment, so a semantic-only deployment no longer stores the episode
  and then raises "Episodic memory is disabled" on the same request. The
  MCP tools keep passing ALL_MEMORY_TYPES, which now means every type the
  server has.

- The shadowed _cleanup_semantic_history is removed; the surviving one is
  called only when semantic memory is enabled, matching the guard
  _delete_queued_session already applied to the semantic delete itself,
  and delete_episodes resolves the semantic service under the same guard.

The integration conftest built a complete SemanticMemoryConf without
saying enabled=True and relied on the lazy build; it now says it. The
batched deletion test flips semantic memory on so its per-batch cleanup
assertion keeps meaning something.

Fixes MemMachine#1575
Fixes MemMachine#1600

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_018nSC7JKXByD1WADJukvupg

…tup (speedkick)

`semantic_memory.enabled: false` only skipped the semantic service in
start(). Every request path that could name the semantic type still
resolved the semantic stack lazily and used it: add_episodes, query_search
and list_search branched on target_memories alone, and the SemanticManager
getters built storage, config store, embedder and language model on first
use without reading the flag (running Alembic migrations on the request
path for pgvector). The flag changed who paid to bring the stack up, not
whether it came up. With a complete config the request succeeded and did
real work; with the incomplete config that MemMachine#1580 now produces by default,
get_semantic_storage raised from inside the request.

Deletion had the same gap with a twist. memmachine.py defined
_cleanup_semantic_history twice; both arrived in MemMachine#1151. The later
definition, which requests the semantic service unconditionally, shadowed
the earlier one that caught ResourceNotReadyError, so with semantic memory
disabled every project deletion raised in the worker, dropped the job, and
left the session in `delete` status for good (MemMachine#1575). delete_episodes
requested the service unconditionally too.

Three changes:

- ResourceManagerImpl.get_semantic_manager raises
  ResourceNotReadyError("Semantic memory is disabled.") when the flag is
  off, so nothing semantic is constructed; get_semantic_service and
  get_semantic_session_manager go through it. The flag is read only on the
  server side: MemMachine routes requests, and the composition root refuses
  to build a component the deployment does not have. SemanticResourceManager
  and everything below it never see it. The semantic-only MemMachine
  operations (features, set types, ...) now fail with that message instead
  of building a stack the operator turned off.

- MemMachine gains enabled_memory_types, read from the two configuration
  flags, and add_episodes, query_search and list_search filter
  target_memories through it. A request naming a disabled type gets None
  for that field, exactly as when it did not name the type. Skipping
  rather than rejecting is forced by the client: memmachine_client sends
  both types on every add and search, so rejecting would fail every client
  call against the default configuration. Episodic gets the same
  treatment, so a semantic-only deployment no longer stores the episode
  and then raises "Episodic memory is disabled" on the same request. The
  MCP tools keep passing ALL_MEMORY_TYPES, which now means every type the
  server has.

- The shadowed _cleanup_semantic_history is removed; the surviving one is
  called only when semantic memory is enabled, matching the guard
  _delete_queued_session already applied to the semantic delete itself,
  and delete_episodes resolves the semantic service under the same guard.

- Two more mixed paths reached the semantic stack unconditionally and
  would have started failing on a disabled deployment once the composition
  root refused: the MCP delete tool's _delete_memories called
  delete_features even with no semantic uids named, and delete_all asked
  for the semantic manager before touching the episode store. The first
  now calls delete_features only when semantic uids were named; the second
  touches the semantic stores only when semantic memory is enabled.

The integration conftest built a complete SemanticMemoryConf without
saying enabled=True and relied on the lazy build; it now says it. The
batched deletion test flips semantic memory on so its per-batch cleanup
assertion keeps meaning something.

Fixes MemMachine#1575
Fixes MemMachine#1600

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_018nSC7JKXByD1WADJukvupg