Channel-scoped collaborative workspace grants

[dcellison]

Parent epic: channel settings and shared channel authority.

Problem

Principal workspace grants authorize a person's own runtime choices. They do not authorize publishing a private workspace to a multi-human channel. Channel membership must not implicitly expose /Users/... repositories or a principal's home.

Scope

• Define a canonical, channel-scoped collaborative workspace grant issued by the workspace-owning principal or an authorized administrator.
• Reference an existing canonical principal workspace grant; do not create a second path registry.
• Record grant owner, target channel, workspace identity, display label, lifecycle, revision, and audit provenance.
• Validate the path against the owner's configured workspace base and existing grant rules.
• Provide grant, inspect, and revoke operations with optimistic concurrency and replay-safe operation IDs.
• Expose only safe labels/readiness to channel members; avoid disclosing private paths unless policy explicitly permits it.
• Revocation must immediately make the workspace ineligible for new channel runs and notify dependent bindings.
• Add integrity, orphan, and stale-grant diagnostics.

Acceptance criteria

• Joining a channel does not create a workspace grant.
• Scott cannot discover or select Daniel's private repositories unless Daniel explicitly grants one to that channel.
• Duplicate grants are idempotent and conflicting grants fail clearly.
• Revocation is durable across restart and cannot leave an apparently usable binding.
• The authority is transport-neutral and reusable by future adapters.

Security boundary

This authority permits Kai runtimes to use a workspace for the channel. It does not grant human members shell, filesystem, or operating-system account access.