🐛 fix(auth): make the terms flow work against a real instance

[hub2rock]

Follow-up to #51, which shipped before these two were found. The terms screen as merged cannot load terms from any real instance — it fails with "couldn't read the server's response".

1. The terms payload has no type

planka-openapi.json lists type under the terms item's required keys. Neither demo instance sends it:

{"item":{"language":"en-US","content":"# ⚠️ THIS IS ONLY A TEMPLATE…","signature":"2796eed…"}}

Declaring it non-optional failed the whole decode. It is now optional, with a regression test built from the observed response.

Also splits the body at PLANKA's [confirmations]:: marker. The statements after it are what the user is agreeing to, so they belong beside the accept button — left in place the marker renders as a literal line in the middle of the terms.

2. An unavailable language does not fall back to English

Asking GET /terms for a language an instance does not have returns whichever it lists first, not English. Verified against a de-DE/en-US instance:

GET /api/terms?language=fr-FR  →  "language":"de-DE"
                                  "# ⚠️ DIES IST NUR EINE BEISPIEL-VORLAGE…"

Passing the device language straight through would have asked a French user to accept legal terms in German. Bootstrap.termsLanguages is now read first and the choice made client-side: the user's language, then a regional variant, then English, and only then the instance's first.

Community vs Pro

Both editions' demo instances were checked, since the two can drift:

	Community 2.2.1	Pro 2.4.1
GET /terms payload	identical — no type, same [confirmations]:: marker	identical
bootstrap fields	termsLanguages, version, isDemoMode	adds branding, maintenance, oidc

The bootstrap difference is already safe: every field except version is optional in Bootstrap, so Community's leaner payload decodes. oidc being absent there matches SSO being a Pro feature.

Not verified: the login POST on a Community instance. curl is unavailable in this environment and WebFetch only does GET, so whether Community's 403 carries the same pendingToken / step is unconfirmed — the GET-side payloads being byte-identical makes it likely but not certain.

Verification

176 tests (8 new), app builds, lint clean, localization guard passes.

🤖 Generated with Claude Code