memory: index lock should follow the configured state backend (machine local for orphan/two-layer), not always land in .squad/backend/ #2379

Follow up from the security review of #2356 (memory index lock), non blocking, found by Worf.

Finding (SEC-2, medium): LocalMemoryStore takes its lock at {teamSquadDir}/backend/locks/memory-index on disk regardless of the configured backend (packages/squad-sdk/src/memory/index.ts:657-671). For orphan, git-notes and two-layer backends this contradicts the repo invariant in backend-mcp.ts:146 (a configured backend keeps its locks machine local, nothing lands in .squad/backend/, see state-backend-store.ts:142-186 resolveLockDir / machineLocalLockDir).

Consequences

• Two linked worktrees or two checkouts sharing one orphan squad-state ref write the same index.json but take different locks, so the lost update race persists for exactly the multi worktree case that motivated shared backends. Not a regression, the old in process mutex never covered it either, but the changeset wording "across local store instances and processes" over claims.
• .squad/backend/locks/ gets created in every project using memory. Mitigated by the .squad/backend/ gitignore entry added in upgrade, only an empty dir remains, but pre preview.1 repos that never ran squad upgrade will see an untracked directory.

Ask

• Route the lock through the backend aware resolution (createStateBackendStore(backend, { lockAnchor: squadDir }) style) when storage is not an FSStorageProvider, so configured backends lock machine locally and share the lock across worktrees.
• Tighten the changeset wording to what is actually covered.

Reference: #2356, #2334.