Org/scope policy to disable public bearer session shares #1096

Need

Allow an administrator to enforce authenticated-only session sharing for an organization or sensitive scopes. Our production-derived conversations must never be published through QM's public bearer links, while permitted internal collaboration remains available. Read-only database credentials do not prevent sensitive query results appearing in assistant replies or delivered files.

Current upstream evidence

Source reviewed at b3f119560592a2727ffdb095f2df18dad9ce97af (separately checked against our older deployed private release; public links below refer only to upstream):

• createShare accepts internal or external, requires an internal creator with viewer access to the source, but has no org/scope external-sharing policy check. This is viewer access, not an owner-only publishing permission.
• readShare checks recipient identity only for internal shares. External transcript and file reads still check the creator's internal status and continued source access, but not a current public-sharing policy. Core routes use signed source authentication; the public recipient is not authenticated.
• Web server routes /share/external/... without signing the recipient in and forwards to dedicated core projection/file endpoints. Creation forwards the authenticated user's identity, not a browser-supplied creator.
• Sharing documentation explicitly describes unauthenticated viewing/downloads, retained assistant replies and attachments, and no update/revoke controls. Excluding raw tool results does not remove sensitive information already included in final text/files.
• Share UI offers “Anyone with the link”; its warning is advisory.
• Existing SharingPosture (isolated/open) concerns reading personally entitled resources across conversation contexts. ScopedConfigStore provides org/scoped governance, but the snapshot routes above do not consult it. This request is specifically the external snapshot publication/read boundary, not a replacement for that resource-sharing posture.

Desired contract / acceptance

1. An authorized administrator can disable public session sharing organization-wide, with sensitive scopes able to impose an equally strict or stricter policy. A narrower scope/user or creator role cannot bypass an org prohibition. Fit existing governance/config conventions; no new policy framework required.
2. With authenticated-only policy effective, server-side creation rejects audience: external before persisting a snapshot or copying share bytes. Applies to direct API requests and every UI/source route, regardless of creator operator/developer/admin role. Internal sharing remains available subject to its normal authentication/authorization rules.
3. Re-evaluate effective policy on external transcript and attachment reads. Tightening policy makes preexisting external links unavailable, even while their creators retain source access. Specify behavior for legacy shares whose scope cannot be resolved; do not silently allow them around the prohibition.
4. UI reflects allowed audiences and explains policy rejection, but hiding a button or adding a prompt is not enforcement. Policy management remains subject to existing administrator authorization.
5. Cover organization ceiling, scope restriction, direct create rejection without stored snapshot/bytes, old-token transcript/download denial after tightening, and permitted internal sharing. Existing creator-access revocation behavior must remain intact. Unrestricted scopes retain explicitly allowed external sharing behavior.

Boundary

This prevents accidental or intentional publication through QM's own session-share link feature. It is not DLP and cannot stop an authorized reader manually copying text, screenshots, or downloaded files elsewhere. No content classifier, automatic sensitivity detection, or broad sharing redesign requested; explicitly governed production-derived/sensitive scopes suffice (org-wide prohibition covers the whole deployment).

Searched existing issues for sharing, session sharing, external shares, bearer links, and sharing posture. #129 addresses broader data/KPI governance, not this enforcement seam; #1093/#1094 concern MCP authentication/entitlements, not output publication. No matching issue found.

Verification: source inspection only. No live share links created, exploit attempts, database access, deployment changes, or functional tests.