fix(auth): check a workspace's personal-key switch after membership - #9540

Summary

• authorizeWorkspaceOperation refused a personal API key or OAuth token on a workspace with personal keys switched off before checking membership. Workspace use cases load their canonical context before authorizing, so a non-member got 403 PERSONAL_API_KEYS_DISABLED for a resource that exists and 404 for one that doesn't. With v2 file routes accepting guessable files/… paths, that is a practical file-existence oracle for those workspaces.
• The column check now runs right after the role check, like the permission-group key beside it already did, for the same reason. A non-member gets the concealed NoWorkspaceAccessError (404 on v2). A member still gets PERSONAL_API_KEYS_DISABLED. The only visible change for members: one whose role is also too low gets the insufficient-role 403 first (still a 403).
• Costs one permission lookup, and only for a key hitting a workspace that disabled them.
• Same ordering exists in project-file authorization, audit-log and billing reads, and the v2 chat route; left for a follow-up so this change stays one shared site.

Type of Change

• Bug fix

Testing

• workspace-authorization.test.ts: the case that pinned column-before-role is inverted ("conceals the workspace before refusing the workspace personal-key column"); it fails on the old order
• Table and workspace-file authorization cases that pinned "no permission lookup" now assert a member's refusal
• All 39 suites touching disabled personal keys: 908 tests pass
• biome, check:comment-hygiene, check:test-patterns; rest in CI

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)