fix(auth): allow API keys to manage workspace tables

[mcm]

Problem

Every endpoint in tracecat/tables/router.py was declared with WorkspaceUserRouteRole, which sets allow_api_key=False. Service-account API keys were therefore rejected with 403 before the per-endpoint require_scope(...) check ever ran, regardless of which table:* scopes the key actually held.

On top of that — and what makes this PR broader than the recent siblings — the table:* scopes were never added to the service-account assignable allowlist (WORKSPACE_SERVICE_ACCOUNT_ASSIGNABLE_SCOPES). So even after flipping the dependency, admins couldn't actually grant table access to an API key. This PR opens both halves.

Changes

• tracecat/tables/router.py — swap WorkspaceUserRouteRole → WorkspaceActorRouteRole on all 18 endpoints (and the import). Actor is a superset of User, so user-session callers see no behavior change.
• tracecat/service_accounts/constants.py — add table:read, table:create, table:update, table:delete to WORKSPACE_SERVICE_ACCOUNT_ASSIGNABLE_SCOPES. ORG_SERVICE_ACCOUNT_ASSIGNABLE_SCOPES picks them up via union, no separate edit. The scopes themselves are already defined in tracecat/authz/scopes.py (present in the VIEWER / EDITOR / ADMIN preset sets).
• tests/unit/test_service_accounts_validation.py — table:read and table:create move from the workspace "rejects user-only" parametrize list into the "allows supported API-key" list, alongside the new table:update / table:delete. Same shuffle on the org-variant lists.

Compatibility

• User sessions: unchanged. Actor accepts User callers the same as User does.
• Existing service accounts: unchanged. The new scopes are merely assignable — no key is automatically granted table:*. Admins must explicitly grant them, same as any other scope.
• Migrations: none required.

Precedent

Follows the same route-role-swap pattern as #2759 (workspace variables and case attachments). This one is the broadest of the recent series because it adds entirely new entries to the service-account assignable allowlist, rather than just flipping a dependency on routes whose scopes were already assignable.

Test plan

• ruff check clean on changed files
• ruff format --diff clean on changed files
• basedpyright --warnings reports 0 errors / 0 warnings on changed files
• CI test suite (pytest requires the full docker stack; deferred to CI)

---

Summary by cubic

Allow service-account API keys to manage workspace tables by enabling API-key access on tables routes and making table:* scopes assignable. User sessions are unchanged; admins can now grant table:read|create|update|delete to service accounts.

• Bug Fixes
  • Swapped WorkspaceUserRouteRole → WorkspaceActorRouteRole on all /tables endpoints so API keys aren’t rejected before scope checks.
  • Added table:read, table:create, table:update, table:delete to WORKSPACE_SERVICE_ACCOUNT_ASSIGNABLE_SCOPES (org allowlist picks them up via union).
  • Updated scope-assignability tests to reflect the new table scopes.

^{Written for commit 33a2653. Summary will update on new commits. Review in cubic}

[zeropath-ai]

✅ No security or compliance issues detected. Reviewed everything up to 33a2653.

Security Overview

• 🔎 Scanned files: 3 changed file(s)
• 🔗 Scan Link: https://zeropath.com/app/repositories/00dffd6c-8834-4dc9-b6d8-b44cd1622986?scanId=3d4c0900-93a0-4d60-822f-0bc50ca96673&codeScanTypes=PrScan&tab=issues

Detected Code Changes

Change Type	Relevant files
Configuration changes	► tests/unit/test_service_accounts_validation.py     Add table scopes to test data ► tracecat/service_accounts/constants.py     Add table scopes to constants
Refactor	► tracecat/tables/router.py     Replace WorkspaceUserRouteRole with WorkspaceActorRouteRole

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}