feat: API token management in workspace settings

[dnplkndll]

Summary

• Add full API token CRUD (create, list, revoke) as a new workspace settings page
• Tokens are workspace-scoped JWTs with configurable expiry (7–365 days), stored in a new api_tokens table
• New createApiToken, listApiTokens, revokeApiToken account service RPC methods
• Frontend: settings page with token list, status badges, create popup with one-time token reveal

Changes

Backend (server/account/):

• ApiToken type + apiToken DB collection (Postgres V25 migration + Mongo)
• Three new RPC methods registered in AccountMethods and getMethods()
• AccountClient interface + implementation extended

Frontend (plugins/setting-resources/):

• ApiTokens.svelte — workspace settings page (Owner role)
• ApiTokenCreatePopup.svelte — creation modal with workspace/expiry selection
• Registered as WorkspaceSettingCategory in the model

Test plan

• Create an API token from workspace settings → token appears in list
• Copy token from one-time reveal popup → verify JWT decodes correctly
• Use minted token with transactor REST API (/api/v1/find-all/{workspace})
• Revoke a token → status changes to "revoked"
• Token list shows correct status (active/expiring/revoked/expired)
• V25 migration creates api_tokens table on fresh and existing databases

Ref: #10622

🤖 Generated with Claude Code

[huly-github-staging]

Connected to Huly®: UBERF-15850

[dnplkndll]

Follow-up: REST API should apply sensible defaults for TxCreateDoc

While testing the token management flow end-to-end (mint token → create issues via REST), I discovered that POST /api/v1/tx/{workspace} passes TxCreateDoc transactions through with zero default-filling. Issues created this way are missing fields that the UI auto-populates, causing them to not appear in project views (only in all-issues).

Missing fields for tracker:class:Issue

When the UI creates an issue, it uses addCollection() which wraps the TxCreateDoc in a TxCollectionCUD, setting:

• attachedTo: tracker:ids:NoParent
• attachedToClass: tracker:class:Issue
• collection: "subIssues"

Plus these attributes that get no server-side defaults:

• kind → must be tracker:taskTypes:Issue (not tracker:ids:ClassingProjectType)
• childInfo: [], parents: [], subIssues: 0, comments: 0, reports: 0
• assignee: null, component: null, dueDate: null
• estimation: 0, remainingTime: 0, reportedTime: 0

Impact

Issues created via bare TxCreateDoc (the natural REST usage) are invisible in project views because the Svelte live query filters on attachedTo/collection. They show up in the all-issues aggregated view only.

Possible approaches

1. Document it — update REST API docs to show the required TxCollectionCUD wrapper pattern for issue creation
2. Server-side defaults middleware — a new middleware in the tx pipeline that merges missing fields from the model schema for known classes (significant arch change)
3. Higher-level REST endpoints — add POST /api/v1/create-issue/{workspace} that accepts a simplified payload and constructs the full TxCollectionCUD server-side, like the importer does

Option 3 seems most API-friendly without changing the platform's "caller provides everything" philosophy. Happy to contribute this if there's interest.