Confluence import: wizard UI, client, and i18n

[Willyfrog]

Layer 7 of 7 in the Confluence page import stack, split out of #18. The design narrative and the accepted risks live in #18 — read it first; this PR is one layer of it.

Stack order: #30 → #31 → #32 → #33 → #34 → #35 → #36

The wizard and everything in front of it. Top of the stack — merging this makes the feature complete.

What's here

The wizard (import_wizard and its source/upload/review/progress/result steps), the typed client (client/imports.ts), the polling hook (hooks/imports.ts), types, the sidebar entry points, and the i18n strings.

What to look for

• The step is derived from the job, never tracked locally, so the wizard follows the server backwards as well as forwards. Try to find state that would desync on a reload or a server-side regression.
• The URL carries the import because a job outlives any one view of it — a reload mid-run must land back on the running job.
• Polling is the correctness floor. The WebSocket import_job_updated event is a latency layer over it, not a replacement; polling alone must be correct.
• Conflict approval is per-page and individual. Check the review step can't approve more than what was shown.
• Error, empty, and degraded states — a server-side failure mid-wizard should be legible, not a blank step.

Known gaps, deliberate (see #18)

Link counts in preflight/final summaries are unpopulated; no past-imports view (listImportJobs already backs one if wanted); phase 7 end-to-end validation against a real mmetl fixture is not in this stack.

Verification

tsc --noEmit clean. 557 tests across 76 suites, all passing.