Confluence import: HTTP API, reports, and plugin wiring

[Willyfrog]

Layer 6 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 HTTP surface, the streaming report downloads, and the plugin wiring that makes the feature reachable. Everything below this layer is inert; this is where the import becomes a thing a user can invoke.

What's here

api_import.go, plus the wiring in api.go and plugin.go, the test fixture generator (internal/importfixture, cmd/genimportbundle), and the API-level test suites — which exercise the whole stack beneath, so they are the closest thing to integration coverage in this stack.

What to look for

• Permission gating on every endpoint. Confluence page import: importer, worker, execution, reports, and wizard #18 states the accepted risk plainly: any Space member can attribute imported pages to any user, and the bundle is unsigned. That is the plan's intent (§18.4) — but confirm no endpoint is looser than that intent.
• Two report downloads (the approved plan and the outcome) exist so they can be compared. They stream, and they must state their own consistency rather than silently emitting a hybrid.
• Wiring — plugin.go is where the worker starts. Check its lifecycle against plugin deactivation: a worker that outlives the plugin is a leak.

Verification

go build ./..., go vet ./... clean. Full server suite green (forced, uncached): server, app, importer, model, store.