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

[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 (#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. #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`.

Read the tenant and ownership migrations in #778 and #774 first, then inspect ext_apps/apps.py:112 and mcp_server/app_tools.py:520-528 alongside the resource persistence and access paths. Done means visibility is included with the tenant/owner schema, private-only states are enforced across creation, updates, imports and reads, invalid states fail closed, and catalogue copies remain private.

Written by the indexing model from the issue text.