Platform should refuse to register a write action with no authorization clause #799

Related app-level finding: proappstore-online/chess-academy#117.

The pattern: on this platform, registered actions (defined in each app's mcp.json) are the real security boundary - any authenticated session can call any registered action directly, bypassing the app's UI entirely. Nothing on the platform side verifies that a write action (execute or batch) actually contains an authorization/ownership check in its SQL. If an app's UI enforces a rule (role, ownership, status, tier, format) but the corresponding registered action's SQL doesn't also enforce it, the rule is not enforced at all for a caller who calls the action directly.

A sweep on chess-academy (#117 there) found four real instances of exactly this gap, three with direct consequences on a children's product: an unrestricted logo URL field enabling third-party tracking on a public sign-in page, a one-directional game-clock guard enabling an undetectable clock cheat, and unrestricted late player additions silently corrupting an active round-robin tournament's fairness. All were only visible by reading the SQL directly and asking what does this allow a caller who never loads the page - review of the UI code gave no signal.

This is a systemic gap in the platform's guardrails, not just a one-off app mistake: nothing stops any app on the platform from registering a write action with zero enforcement, and nothing flags it when it happens.

Proposed scope:

1. At action-registration time (or as a CI/build-time lint over each app's mcp.json), require every execute/batch action to reference some form of caller-scoped authorization in its SQL (e.g. an EXISTS clause against user_roles keyed on the calling user, or an equivalent convention already used across apps).
2. Reject or hard-fail registration/build for any write action that has no such clause, with a clear error naming the offending action.
3. Make sure this check itself doesn't have the same blind spot chess-academy's own test had - it must inspect the statements array for batch actions, not just a top-level sql field, since that field is undefined for batch actions and would silently skip them.
4. Document the requirement and the exact accepted pattern(s) for satisfying it, so app developers have a clear rule to follow rather than rediscovering it per-app.

Goal: make it structurally impossible for a new registered action to ship on any app with no enforcement, rather than relying on each app remembering to do its own audit.