feat(widget): scoped widget profiles and ticket submission

[melihsunbul]

What

Scoped widget profiles (applications and environments) and end-to-end ticket submission from the embeddable widget.

Concepts

• Application — a product/site that embeds the widget. It owns an origin allow-list so the widget only runs where you intend.
• Environment profile — a named configuration under an application (for example production vs staging) carrying config overrides, content filters and support categories.
• Signed context token — a tamper-evident token that pins the application/environment a widget session belongs to, so support access can be scoped per profile.
• Scoped support access — chat, tickets, public feedback, help centre and changelog are only reachable through the categories/inboxes a profile is configured for.

How it works

• Domain/schema — domains/widget-profiles/ service plus widget-profiles config (origin allow-list, signed context tokens, per-profile overrides, content filters, support categories).
• Widget package (packages/widget/) — the SDK passes application/environment context through the bootstrap snippet; ticket submission, a resilient browser queue, disabled-state teardown and Home-only navigation; new __tests__ (browser-queue, sdk, tickets).
• Server/widget and API (server/widget/, /api/v1/widget-profiles, routes/api/widget/) — config JSON, session, identify (email identify routed through the API), search, kb-search, upload, sdk.js; scoped access enforced across chat/tickets/feedback/help-centre/changelog with audit events and client-side redaction (redact-portal-config).
• UI — /admin/settings/widget and /admin/settings/portal-widget (profile management and preview); components/widget/.

How to use

• Create an application and profile: Settings → Widget (/admin/settings/widget) — add the application, list its allowed origins, then add environment profiles with their overrides, content filters and support categories.
• Embed: copy the bootstrap snippet; it carries application/environment context to the SDK.
• Tickets from the widget: end users submit tickets that are routed through the profile's support categories and inbox defaults.
• Portal widget: configure the portal-embedded widget at /admin/settings/portal-widget.

Safety

• Widget origins are validated, context tokens are signed, and portal config is redacted before it reaches the client.
• Support access is scoped per profile, so a widget can only reach the categories/inboxes it is configured for.

Verification

• bun run typecheck, bun run lint; widget unit tests (browser-queue, sdk, tickets) and widget route/API tests (included).

Depends on 06-github-sync-and-ticket-email.

---

📚 This is a stacked series — please review & merge in order

These 10 PRs are split by concern and ordered by dependency. Each is opened against main, so until the PRs before it have merged, a PR's diff is cumulative (it also contains the earlier batches). As the earlier PRs merge and we rebase the next branch onto main, each diff reduces to just its own batch. Merging all 10 in order reproduces our integrated branch exactly (verified: the cumulative tip of the series is byte-identical to it).

Order (by branch):

1. 01-data-model-foundation — data model, TypeIDs, migrations
2. 02-rbac-authz-teams — RBAC, teams, organisation & auth surfaces
3. 03-events-audit-webhooks — event dispatch, audit log, webhooks, notifications
4. 04-ticketing-crm-core — ticketing / CRM core
5. 05-sla-inboxes-routing — SLA policies, inboxes, business hours, routing
6. 06-github-sync-and-ticket-email — GitHub ticket sync, ticket email, integration platform
7. 07-widget-profiles — scoped widget profiles + ticket submission
8. 08-api-openapi-mcp — OpenAPI surface, MCP tools, conversation actions, API keys
9. 09-content-visibility — changelog/help-centre visibility, segments, portal tabs
10. 10-test-coverage — broad unit/integration test suite + supporting infra

Part of the roadmap: #283

[CLAassistant]

All committers have signed the CLA.