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

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.