[Feature] Add an authorization regression matrix for admin, member, user, anonymous, widget, API-key, and MCP access

[richardcmckinney]

Problem

The codebase has many authorization surfaces: server functions, TanStack routes, public API, widget bearer sessions, portal sessions, API keys, OAuth, and MCP tools. A small change in one auth path can unintentionally widen access elsewhere.

Proposed solution

Create a reusable authorization test matrix that enumerates each route/function/tool and expected access for anonymous visitors, portal users, members, admins, widget sessions, scoped API keys, OAuth tokens, and MCP clients.

Acceptance criteria

• Every server function and API route has an explicit auth expectation.
• Every MCP tool declares required role and scope.
• Tests assert allowed and denied outcomes for each principal class.
• CI fails when a new route/function/tool is added without an auth expectation.
• Test fixtures include admin, member, portal user, anonymous widget, verified widget, unverified widget, scoped API key, full API key, and OAuth client.
• The matrix is documented so contributors know where to add coverage.