Multi-member deployments: nobody can administer the deployment Agent (all six Agent endpoints return bot/blocked-shared) #614

Summary

After #612, when a deployment has more than one member, nobody can administer the deployment's own Agent or its Session: all six Agent endpoints (add-agent and the five owner-scoped ones) answer bot/blocked-shared. This is the add-agent rule applied consistently — but the agent is one per deployment and carries no owner, so with two members the "owner" check has nothing to match and the default is deny.

Evidence

• Fix owner-scoped access for Agent endpoints and delete answers #612 (fix/agent-endpoints-signed-in, T3, PASS) puts the six endpoints in SHARED_BLOCKED; the Reviewer's read of the tip: with more than one member all six return bot/blocked-shared (core/src/host/authz.js).
• add-agent already had this rule, so this is consistent rather than a regression: the DSH Agent is one per deployment and has no owner, exactly like add-agent.
• Single-member deployments are unaffected (the owner matches); the block only appears with 2+ members.

Expected behavior (needs a product decision)

Either:

1. Only one member is supported — say so explicitly: the Agent and its Session are owner-only, and a multi-member deployment shows "this deployment's Agent is managed by its owner" instead of a bare bot/blocked-shared; or
2. Multi-member deployments make the Agent manageable — an explicit rule (e.g. the deployment owner from config, or a signed-in member the owner promoted) may add/adopt/archive/rename the Agent and remove agents, with the rule written down and a test for the denied cases.

Whichever is chosen, the failure should be a readable message, not a permission code, and docs/subsystems/team.md / the authz rules should state who manages the deployment Agent.

Change scope

core/src/host/authz.js (the SHARED_BLOCKED handling for the Agent endpoints, and the message), the client path that surfaces bot/blocked-shared, core/test/authz.test.js, the docs that describe owner-scoped access.

Blocking

The ball is with the user (through the Chief): is a single-member deployment enough, or must a multi-member deployment's Agent be manageable? The answer decides which of the two shapes above is built. No code change should guess it.

Why

It is not a security hole — it is the consistent application of a real rule — but a team deployment today has an administratively unreachable Agent, which will bite the moment team mode is used.