[Feat] Sharing and visibility within a tenant (schema in 3.0, experience after)

[haofeif]

[Feat] Sharing and visibility within a tenant (schema in 3.0, experience after)
Part of #777 (CAO 3.0). Depends on the tenant model (#778) and ownership (#774).

In plain terms

If everyone's work is private and nothing can be shared, a team server is just several private servers that happen to run on the same machine. The reason a team wants a shared CAO is to share things — a workflow that deploys the service, an agent profile the whole squad uses.

So "keep people apart" cannot mean "wall everyone off completely". It means private by default, shared on purpose.

CAO has no concept of this today. There is no way to mark anything as shared, because there is nobody to share it with.

The scope of this issue, and why it's split oddly

This issue is deliberately in two halves, and only the first half is in 3.0.

The schema is in 3.0. Define visibility with the tenant/owner resource model that #774 and #778 are already migrating, and apply its private-only rule consistently to writes, reads and imports. The benefit is a shared access contract for later features, not a claim that another column would necessarily rewrite every table or that the visibility work is free.

The experience is after 3.0. Actually sharing things — the interface for it, sharing with a subset of a tenant rather than all of it, transferring ownership — is real product design and shouldn't be rushed to hit 3.0.

So 3.0 ships with user-owned work private and a visibility field enforced on both reads and writes. This establishes the ownership/visibility foundation for later sharing; it does not promise that team/project audiences, grants or ownership transfer will never need additional schema.

This split is the whole point of the issue. If it feels like an odd shape, that's why.

What this delivers

In 3.0:

• Every shareable user-owned record carries a visibility that the code reads and respects.
• Private is the only enabled state, not just the default. Creation, updates, imports and API/MCP calls cannot turn on sharing merely because the interface has no sharing button; reject unsupported sharing requests explicitly.
• Visibility can never widen past the tenant. "Shared" means shared with your organisation — never public, never across tenants.
• The packaged/operator-published read-only catalogue is a separate resource class ([Feat] Tenant model and isolation boundary: make an organisation a first-class thing in CAO #778), not private user work made public through this field. A user's copy is private and cannot modify the original.

After 3.0:

• Sharing and un-sharing from the interface.
• Sharing with a team or project rather than the whole tenant.
• Transferring ownership when someone leaves.
• What happens to shared work when its owner is removed. (Safe to defer only because user-resource sharing is disabled across all 3.0 write paths. [Feat] Tenant administration: roles, member management, and revocable sessions #779 defines the fate of a removed person's private work.)

Acceptance criteria

• Visibility lands in the same migration as tenant and owner — not a later one.
• User-owned work, including migrated 2.5 data and copies of catalogue items, is private.
• Unsupported non-private values are rejected on creation, update and import through every exposed client/API, not merely hidden in the UI.
• Every read path honours visibility rather than ignoring the column.
• Neither reserved sharing values nor invalid stored values expose user-owned work to another member or tenant in 3.0. Invalid states fail closed and are reported rather than silently granting wider access.
• Read-only catalogue use still works without becoming a loophole for publishing or mutating another person's private content.
• On a laptop, everything belongs to the single local user and visibility is invisible in the interface.

Evidence

Claim	Where
No resource-sharing policy exists	Existing resource persistence/access paths have no such policy; the visibility in ext_apps/apps.py:112 and mcp_server/app_tools.py:520-528 is MCP UI metadata, not resource access control
The tables that would carry it are already being migrated	#774, #778

All repository observations verified on main at 29b235cf62ed0f9d624bc9ad9afce09ab72f8ddf.