bug: local-to-orphan migration leaves existing governed memory unavailable through MCP #2425

Migrating an existing Squad from local to orphan leaves governed memory in the working tree while the MCP memory tools switch to the orphan branch. Previously stored memory then becomes unavailable through those tools, even though the original files remain on disk.

Affected version: Squad CLI/SDK 1.1.0, Homebrew standalone installation on macOS. Source references below are pinned to release commit c24da2aad2ab7576f6b68dec2bc50b2fe2dc7a8a. This report is based on source inspection of that release and its installed bundle.

Expected behavior

Existing durable governed memory should remain available through memory.search after squad upgrade --state-backend orphan, with one authoritative store. The release's migration documentation promises preservation of existing state.

Source evidence

• collectWorktreeState() collects only decisions.md and agents/<name>/history.md. It never collects memory/ records, index, configuration, audit history, or tombstones.
• migrateStateBackend() nevertheless changes stateBackend to orphan after importing those selected files.
• createStateMcpToolRegistry() obtains storage from resolveSquadState(). The resolver selects StateBackendStorageAdapter for orphan storage, so MCP reads no longer consult the old filesystem memory store.
• The same migration collector remains in the current dev source at the time of filing.

Reproduction scenario derived from the source

1. Start with stateBackend: "local" and a governed LOCAL memory written through MCP memory.write.
2. Confirm that MCP memory.search can find it.
3. Run squad upgrade --state-backend orphan and reconnect the MCP session so it resolves the new backend.
4. Search for that memory through MCP again.

The record and index remain under the on-disk .squad/memory/, while MCP now reads squad-state:memory/.... The migration never imported the pre-existing memory. squad sync --push only synchronizes existing state refs; it does not import those filesystem files.

Scope

This is a visibility/authority migration defect, not a claim that the old files are deleted. This report does not require transient logs, scratch files, or sessions to migrate.

This is distinct from #2316 / #2317: making CLI and MCP use the same configured store does not transfer existing local memory when changing backends. Any migration should preserve existing destination state and retain the source until a successful transfer is established.