Confluence import: model vocabulary and schema

[Willyfrog]

Layer 2 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 vocabulary and the schema. Everything above this layer is written in these terms, so this is the layer to disagree with early — a wrong state or a missing constraint here is expensive later.

What's here

• model/import.go — job states, phases, actions, outcomes, issue stages/severities, and the record types.
• model/import_report.go — the report record shapes.
• model/page_content.go — sentinel errors (ErrTipTapBodyTooLarge, ErrTipTapTooDeep, ErrTipTapTooManyNodes) and exported MaxTipTapNodes/MaxTipTapDepth, so the importer and the page sanitizer share one set of limits instead of two that can drift.
• migrations/000006_create_imports.{up,down}.sql — the schema.

What to look for

• Is the state partition total and disjoint? IsTerminal, IsWorkerOwned, and AwaitsUser divide ImportJobState. A state in neither of the last two is a job nobody advances.
• Do the constraints and indexes actually back the CAS transitions the store layer does above this? A compare-and-set that isn't backed by a unique index is a race waiting for load.
• The two-pool retained accounting (mandatory per-entity outcomes reserved up front, plus a flat discretionary allowance) — is the reservation arithmetic in IssueBudgetRemaining right at the boundaries?
• The down.sql — does it actually reverse up.sql?

Verification

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