feat(pkg): proxy IRMA /statusevents SSE endpoint

[dobby-coder]

What

Adds a PKG-server proxy route that forwards the IRMA server's /statusevents Server-Sent Events endpoint, so clients can use yivi-client's default serverSentEvents: true behaviour instead of polling.

GET /v2/{irma|request}/statusevents/{token}
  → {irma_url}/session/{token}/statusevents

Why

Per #93, the PKG proxies the IRMA session endpoints (/start, /jwt/{token}, /key, …) but not the SSE /statusevents endpoint, which forces clients to disable SSE and fall back to polling. Polling adds up to 500ms latency before detecting session completion, generates repeated HTTP requests instead of one persistent connection, and requires the eventsource shim workaround in browser-extension builds.

How

• New handler pg-pkg/src/handlers/statusevents.rs: makes a GET to {irma_url}/session/{token}/statusevents and streams the upstream text/event-stream body straight back with HttpResponse::streaming (no buffering), so events reach the client as soon as the IRMA server emits them.
• Response headers set for SSE: Content-Type: text/event-stream, Cache-Control: no-cache, and X-Accel-Buffering: no (so nginx in front of the PKG does not buffer the stream).
• Registered inside the existing /{_:(irma|request)} scope, right next to the jwt proxy. Like jwt, the route is unauthenticated: the token is the requestor session token and the endpoint only relays session-status events, which carry no key material.
• Enables the stream feature on reqwest for bytes_stream().

Tests

Two new tests in statusevents.rs (full workspace suite: 36 passing, cargo fmt --all -- --check clean, clippy clean):

• statusevents_proxies_sse_body_and_content_type — spins up a one-shot fake IRMA server over a raw TCP listener that returns an SSE body, drives a real request through the route, and asserts the streamed body and headers are forwarded verbatim.
• statusevents_maps_upstream_error_to_503 — points at a closed port and asserts the connection failure surfaces as an error response rather than panicking.

Notes for reviewers

• This is the server-side half only. The client-side change (flipping serverSentEvents: true and dropping the eventsource shim in @e4a/pg-js / the addons) lives in the postguard-js / addon repos and is out of scope here.
• reqwest::get creates a fresh client per call, matching the existing jwt handler; the default client has no overall timeout, which is what an SSE connection needs.

Closes #93

🤖 Generated with Claude Code

[dobby-coder]

Rules + review gate — verdict: APPROVE (posted as COMMENT because GitHub blocks a bot from approving its own PR; treat this as a clean sign-off, not withheld approval).

Per-rule check (against all-rules.md) + Review Dobby 2's findings, all reconciled:

• ✅ Conventional-commit title (feat(pkg): ... — valid scoped type).
• ✅ Closes #93, draft state, cargo fmt --all -- --check clean, no new clippy warnings.
• ✅ Body claims match the diff (no-buffer streaming, SSE headers, reqwest stream feature, unauthenticated route next to jwt). No key material is relayed — consistent with the PKG security notes.
• ✅ Tests required: happy-path + error-path covered.

One nit found and fixed inline (self-authored PR → fixing > looping, per the gatekeeper routing rule): the test statusevents_maps_upstream_error_to_503 was misnamed — it pointed at a closed port (connection refused → Error::Unexpected → 500) and asserted 500, so the actual 503 path (error_for_status() → Error::UpstreamError) was never exercised. Pushed 3d6b195:

• renamed it to statusevents_maps_connection_failure_to_500 (honest about what it asserts),
• added a real statusevents_maps_upstream_error_to_503 that drives a fake IRMA server replying 503 and asserts the PKG maps it to 503.

All 3 statusevents tests pass locally; fmt clean. No remaining blockers.