Identity federation must be provable: real-issuer CI verification, and test doubles users can hold

Follow-on to #337 workstream I and the characterization in #343. Those prove the verifier against a stub issuer served in-process. Two things are still missing before the federation claim is provable rather than plausible, and both are about testing as a product surface, not an internal convenience.

1. Verify against the real issuer, in the one environment that has one. This repository's CI runs on a platform that mints OIDC tokens on request (permissions: id-token: write, then the runner's token endpoint with a chosen audience). A gated test job should request a real token and run it through the real path: TrustedIssuer entry, live discovery, live JWKS, RS256, audience containment, require: rules on repository/ref, and the derived identity's subject and claims asserted against the job's own coordinates. Gated on the token-request environment variables being present, skipped cleanly everywhere else (a laptop, a fork without the permission), so the suite stays honest offline. Per the house rule for new CI checks, it lands advisory for its first window before becoming required. This is the difference between "the stub agrees with our reading of the spec" and "the deployment path works against the issuer people will actually configure".

2. Export the test issuer so users can prove their own policies. The stub issuer behind #343's tests (mint a token with arbitrary claims, serve discovery and JWKS, wrong-audience/wrong-claim/expired variants) is exactly what an operator writing a TrustedIssuer entry, or a plugin author, needs to test their trust policy and their claim rules without a network. It should graduate from a _test.go helper to a supported package (the flowtest neighborhood is the natural home, next to the virtual clock and the stubbed tasks) with a deliberate, small API: choose issuer URL shape (including a path-carrying identifier), claims, algorithms, lifetimes; mint valid and deliberately-invalid tokens; serve the metadata endpoints. The same double should be reusable for any issuer-shaped need (a future broker, transaction tokens, signed webhooks from #337), which is the real test of the API: nothing in it may be specific to one vendor's claim names.

3. Reach flow test. The end state, per the house gate: a flow test can declare the identity a run executes as, and a trust policy plus claim rules can be exercised from a Flowfile-shaped test the way tasks and clocks already are. That makes identity-dependent workflows (approval gates bound to subjects, task-shape rules reading identity.claims) testable by the people who write them, not only by this repo. Scope for this issue is design plus the seam; the spelling can follow the existing flow-test vocabulary.

Sequencing: 2 first (it is extraction plus API design, and 1 wants it for the shared assertions), then 1 (small workflow job plus one gated test), then 3 as its own slice. 1 and 2 should not start until #343 merges, because they refactor the helpers its tests hold.

Start with #343's stub issuer tests and the flowtest neighborhood, including the virtual clock and stubbed tasks. Extract a vendor-neutral test issuer API first, then use it for the gated real-issuer CI test and the flow test seam. Done means users can mint valid and invalid tokens, serve discovery and JWKS, verify trust and claim rules, and declare identity in a Flowfile-shaped test.