feat: add GET /email-template endpoint keyed on API key

[dobby-coder]

What

Adds GET /email-template, which returns the email template pg-pkg has linked to the caller's API key. The key is validated through the existing ApiKey request guard (the same Authorization: Bearer PG-… flow the upload endpoints use), so no new auth path is introduced.

Implements requirement 10 of encryption4all/postguard#81 (Cryptify: email template retrieval endpoint). Sibling work on the PKG side is encryption4all/postguard#86.

Behaviour

Case	Status
Valid key with a template configured	200 + { tenant_id, email_template }
Missing or invalid key	401
Valid key, no template configured	404
pg-pkg unreachable during validation	503

How

• /v2/api-key/validate response and the ApiKey guard now carry an optional email_template, populated when the key validates.
• Branch mapping lives in a pure resolve_email_template helper so every outcome is unit-testable without HTTP.
• The endpoint is also covered end-to-end through the real guard, exercised against a mock pg-pkg server (real reqwest → /v2/api-key/validate round-trip).
• api-description.yaml documents the route and a apiKeyBearer security scheme.

Tests

cargo fmt --all -- --check, cargo clippy --all-targets -- -D warnings, and cargo test --all-targets all pass locally (127 tests, 8 new):

• Pure helper: template returned / 404 no-template / 401 no-tenant / 503 pkg-unreachable.
• Route via guard: valid key returns template, missing key → 401, invalid key (pkg 401) → 401, valid-key-no-template → 404.

Note for review (kept as draft)

This assumes pg-pkg's /v2/api-key/validate will return the linked template in an email_template field. That field is part of the parallel PKG work (postguard#86) and is read with #[serde(default)], so this stays backward-compatible until the PKG side ships. Flagging the contract for a maintainer call before marking ready.

Closes #54

[dobby-coder]

🔍 Rules Dobby 2 — consolidated review (per-rule compliance check + Review Dobby 2 findings)

Posted as COMMENT because GitHub blocks a self-authored bot from APPROVE/REQUEST_CHANGES. Treat this as a sign-off, gated on the documented maintainer contract call below — not as withholding.

Code is clean and ready on its own merits. CI is green — cargo fmt --check, clippy --all-targets -D warnings, and cargo test --all-targets all pass (127 tests, 8 new). The new email_template route is registered in build_rocket, both new Error variants (Unauthorized, NotFound) are handled in the Responder, and the endpoint correctly rejects with 401 rather than degrading to the default tier like the upload flow. Tests cover the pure resolve_email_template helper and the full route end-to-end through the real ApiKey guard against a mock pg-pkg — both the authorized path and the missing/invalid-key paths. PR title is conventional; no duplicate PRs.

On the one carried finding (cross-repo contract): the endpoint depends on an email_template field from pg-pkg's /v2/api-key/validate. I verified this against the live state: encryption4all/postguard#86 is open with no PR, and its issue body lists deliverables but does not yet pin down the JSON field name. So against real pg-pkg today the endpoint returns 404 for every valid key, and email_template is an unverified guess at #86's eventual schema. This is already correctly handled in the PR: the "Note for review (kept as draft)" section documents the dependency, the field is read with #[serde(default)] so it degrades gracefully, and the PR is deliberately held as draft pending a maintainer call on the contract. That is the right disposition — it's a coordination decision, not a code defect, and nothing the bot can resolve until #86 ships.

No changes requested from the bot side. When encryption4all/postguard#86 lands, confirm the field name matches email_template before flipping this to ready.

Parent: encryption4all/postguard#81. Closes #54.