Expose frontendRequest.authorization on SessionData

[rubenhensen]

Since irmago v0.14.0, `POST /session` returns an extra `frontendRequest` block:

```json
{
"token": "...",
"sessionPtr": { "u": "...", "irmaqr": "..." },
"frontendRequest": {
"authorization": "...",
"minProtocolVersion": "1.0",
"maxProtocolVersion": "1.1"
}
}
```

Today this field is silently dropped by serde (no breakage). Exposing it would unlock downstream use cases that drive the IRMA/Yivi frontend directly — most importantly pairing (mandatory by default for IRMA clients since v0.13).

Proposed surface

Add an optional `frontend_request: Option` field to `SessionData`, with at minimum the `authorization` token (the protocol-version pair is much less useful to a Rust consumer and could be lumped into the struct or omitted).

References

• irmago v0.14.0 release
• Pairing was made mandatory by default in v0.13.0 — without the authorization token, irmars-using apps can't currently complete the pairing handshake.

[dobby-coder]

/dobby fix — Expose the frontendRequest block returned by irmago POST /session as an optional frontend_request field on SessionData (carrying authorization, minProtocolVersion, maxProtocolVersion), as described in the issue. Note: irmars is a fork with an upstream remote — pass --repo encryption4all/irmars when opening the PR so it does not target upstream.

[dobby-coder]

On it! I'll expose the fields on and open a draft PR for review.

[dobby-coder]

PR #17 (feat: expose frontendRequest block on SessionData) reviewed and approved — zero violations across all 74 rules. The change is backward-compatible (serde default + skip_serializing_if), exports FrontendRequest cleanly, and ships with 3 unit tests plus an integration assertion. Flipped out of draft and marked ready-for-review.