Support imports: add Zammad as a source

Is your feature request related to a problem?

Teams migrating off Zammad (open-source, self-hosted helpdesk) have no way to bring their historical tickets and message threads into Support (the conversations product). Today the only historical import source is Zendesk (added in #67419), and the imports docs note that "more sources will be added over time." This is a request for Zammad to be one of them — and an offer to implement it.

Describe the solution you'd like

Add Zammad alongside Zendesk under Support → Settings → Imports.

It's a clean fit because the read surface the Zendesk importer already depends on maps almost 1:1 onto Zammad's native REST API, so no new concepts are needed:

Field mapping is mostly renames plus two lookup tables (Zammad state_id → Zendesk-style status, roles) and one inversion (comment.public = !article.internal). Auth is HTTP token or basic — the same shape as the existing agent-email/token flow.

Scope would be read-only: tickets, articles (→ comments), users, and attachments. No writes, no search, no side-loading. It'd sit behind the same beta gating as the Zendesk import, with tests.

One nice property: a native Zammad importer hits the user-supplied https://{host}/api/v1/... directly, so it avoids the hardcoded {subdomain}.zendesk.com host + SSRF pinning that a Zendesk-compatible shim in front of Zammad would otherwise have to fight (DNS/TLS spoofing). Native is strictly cleaner here.

Describe alternatives you've considered

• A Zendesk-compat API shim in front of Zammad (make Zammad speak enough of the Zendesk API to reuse the existing importer). The API translation itself is small, but the importer builds https://{subdomain}.zendesk.com/... with the host effectively pinned, so this needs DNS + private-CA TLS spoofing on the PostHog side — not viable on Cloud, fiddly self-hosted. A first-class importer removes the problem entirely.
• Data warehouse sources — PostHog already has importers for many helpdesks under warehouse_sources, but that's the analytics/query product, not the Support inbox, so it doesn't cover this use case.

Additional context

The main thing I'd like maintainer input on before writing ~15–20 files is shape, since the current importer is Zendesk-specific end to end (ZendeskImportJob model + its own table, the zendesk_import/ Temporal workflow dir, ZendeskImportSection.tsx + zendeskImportLogic.ts):

1. Generalize into a provider abstraction — a shared import-job model with a provider discriminator plus per-provider client/mapper, with Zendesk as the first of N. Cleaner if you expect several sources, but it refactors shipped beta code.
2. Parallel importer — a self-contained zammad_import/ mirroring the Zendesk structure. Lower blast radius, some duplication.

Is there an intended direction for multi-source imports already? Happy to follow whichever shape you prefer and open the PR.

Start by reading the existing ZendeskImportJob model and the zendesk_import/ Temporal workflow, then inspect ZendeskImportSection.tsx and zendeskImportLogic.ts. Confirm the intended provider-abstraction or parallel-importer shape with a maintainer before proceeding. Done means Zammad tickets, articles, users, and attachments import through Support → Settings → Imports with beta gating and tests.