Fix delegated Content identity and receipts

[3mdistal]

Problem

Alice should be able to ask Content's own AI, another app through ask_app, or @agent-native in a verified Slack direct message to change the same exact Content row under her own authority. The observed Slack DM instead reported a partial, misleading inventory: it omitted Alice's actual Personal feedback database and treated top-level system chrome as though it were ordinary user database inventory. Without the original trace, that symptom could come from the wrong principal, the wrong action, or the wrong interpretation, so this PR repairs and tests each boundary independently.

Approach

Verified managed Slack DMs now resolve only to an exact member of the installation organization. They never borrow a deployment default, installation owner, or channel service identity. Managed channels keep their existing scoped service principal, so a mention there still cannot enter Alice's Personal space.

Content discovery now supports immutable space and database IDs and returns system-role collections separately from ordinary databases. Successful row and Blocks-field actions keep using the action contracts from PRs #2779 and #2781; this PR carries their read-back-verified, idempotent receipts through A2A and Dispatch without retaining private property values or block bodies.

What changed

• Fail closed when a managed Slack DM cannot hydrate or authorize its sender; accept an explicit Slack link or verified email only when it belongs to the installation organization.
• Preserve the authenticated user and organization through ask_app, while keeping managed-channel mentions on the channel's service principal.
• Add exact spaceId / databaseId Content inventory, with Files, Favorites, Workspaces, and other systemRole databases returned in a separate collection.
• Add a versioned, signed A2A receipt ledger plus typed A2A data parts and Dispatch ask_app results. Receipts retain the exact scope, row ID/link, revisions, affected IDs, and applied versus replayed result, but exclude row values and block bodies.
• Add package changesets and a pending Content changelog entry.

Safety and operations

There is no migration, flag, enablement, deploy, Slack send, or production Content write in this PR. Legacy signed artifact markers remain readable; new markers use a versioned envelope. Failed identity hydration is distinguishable from an unlinked or denied identity and performs no agent work. Rollback restores the prior routing and receipt presentation but cannot undo mutations already committed by Content actions; those actions' own idempotency and read-back contracts remain the side-effect authority.

This draft depends on the row mutation contract in #2779 and the Blocks mutation contract in #2781. It is intentionally based on codex/content-feedback-block-actions at 7d992b6918c4971e3dac19fb3fbc68055dbfc3c8 and does not absorb either dependency.

Verification

• 212 Core A2A artifact, final-response, continuation-store, and continuation-processor tests pass, demonstrating signed nested receipt preservation and the existing one-claim delivery/retry custody.
• 58 Dispatch tests pass, demonstrating exact managed-DM membership, fail-closed hydration, no deployment-owner borrowing, managed-channel isolation, authenticated ask_app routing, and structured receipt return.
• 4 isolated Content database tests pass against SQLite, demonstrating the exact Personal space content_space_personal_dd0c011c68137c2ae7baa4d672932070, feedback database 7uLr3ect3IIm / document FJk2OZ1SWcZ9, same-name decoy resistance, structural system-collection classification, and denial to a managed-channel principal without a hard-coded inventory count.
• Core, Dispatch, and Content typechecks pass; all 50 repository guards pass; 14 product-record tests and 30 product-impact tests pass; formatting and git diff --check pass.

Real Slack, browser, provider, and production-connected acceptance was deliberately not run. Later acceptance must reproduce and attribute the original DM, verify same-thread replies and exact receipts, exercise delayed/retried delivery and partial failures/timeouts without replay, and compare DM access with managed-channel denial. That evidence remains pending rather than inferred from fixtures.

Review focus

• Can any managed-DM failure path still borrow another effective Content principal?
• Is system chrome structurally separated without hiding ordinary authorized databases or relying on titles/counts?
• Does the bounded receipt retain enough proof for retries and exact read-back without leaking Content values?
• Do the existing continuation claim and terminal-delivery receipts remain the sole Slack dedupe mechanism?

content_product_impact:
  lane: contract_fulfillment
  features:
    - content.feature.durable-foundations
    - content.feature.work-across-every-workspace
  capabilities:
    - content.agent.action-parity
    - content.workspace.multi-scope
    - content.source.spaces-files
  record_change: none
  proof:
    - 270 focused Core and Dispatch identity, receipt, and continuation tests
    - 4 exact Personal inventory and managed-channel isolation tests
    - Core, Dispatch, and Content typechecks plus all 50 repository guards
  rationale: This fulfills the shaped delegation identity and exact inventory boundary while leaving real-interface acceptance, deployment, and merge explicitly pending.

[github-actions]

Visual recap — skipped

The visual recap job did not run for this pull request. This is informational only and does not block the PR.

Recap skipped for 4c91dc3: draft PR.