security: memory list API has no server-side workspace scoping (client-side filter only)

Start with packages/opencode/src/altimate/workspace/memory-api.ts:150-162, memory-sync.ts:742-747, and memory/prompt.ts:203,299 to trace how memory records are listed, filtered, and injected. The issue says the real fix likely requires checking altimate-backend's memory list endpoint. Done means memory listing is scoped server-side by workspace so global blocks from another workspace are not injected into the current session.

Found during v0.9.7 release review (Chaos Gremlin/Privacy Auditor persona, multi-persona review).

MemoryApi.list() (packages/opencode/src/altimate/workspace/memory-api.ts:150-162) fetches every memory record the authenticated credential can see and filters client-side via belongsHere() in memory-sync.ts:742-747. The code's own comment states: "No workspace filter is sent — the service's own query for a caller's records is not scoped by workspace, so narrowing happens in the caller."

For scope === "global" blocks, belongsHere() returns true unconditionally — a global-scope memory block written under any workspace this account has ever bound gets injected into every other session's system prompt, trusted verbatim as '## Altimate Knowledge... Apply it consistently' (memory/prompt.ts:203,299).

Risk: same-account, cross-workspace memory bleed. If a team shares one account/API key across multiple client workspaces, or a user maintains personal + client workspaces, content from one context leaks unlabeled into another. This is a real prompt-injection-via-shared-memory surface, though scoped to same-account (not cross-tenant/cross-customer).

Whether the backend additionally scopes by tenant/team (making this worse — cross-user, not just cross-workspace) could not be verified from the altimate-code repo; needs a check against altimate-backend's memory list endpoint.

Deferred from v0.9.7 because: (1) the whole workspace/memory-mirror feature is gated behind the off-by-default ALTIMATE_WORKSPACE pilot flag — zero impact on GA users; (2) proper fix is server-side workspace scoping, a backend change outside this repo's scope, not a <30min patch.

Downgrade from P0-candidate to deferred was an explicit user decision during the v0.9.7 release review gate.