auth: rehearsing authentication locally takes ten steps and four refusals — a trust policy cannot hold keys inline, `flow keys public` prints a JWK where a JWKS is needed, and no dev posture stands up a local issuer

Observed behavior

What it took at eb8172f to run one workflow as an authenticated caller on this machine, with two tenants, so that tenancy, the signal policy and the audit trail could be seen doing their jobs:

1. flow keys generate --out idp.pem.
2. flow keys public --in idp.pem prints one JWK; a jwks_url serves a JWKS ({"keys": [...]}), so the JWK was wrapped by hand.
3. A web server on loopback to serve the file, because TrustedIssuer has jwks_url and no jwks_file or inline keys (pkg/flowstate/v1/auth/policy.go, fields name kind issuer client_ca_file subject_from audiences algorithms require role namespace namespace_claim namespace_map jwks_url max_token_age).
4. A trust policy, refused once for a missing name (#1693 reports the refusal's wording).
5. Refused again by the identity egress boundary for http on loopback, then again for loopback itself, fixed by an egress: section documented nowhere (#1694).
6. flow server dev refuses ambient authentication by design, so a Temporal had to be started through it and a second flow server --auth-policy --listen --rpc-resource --identity-claim --temporal-address beside it.
7. Tokens signed with flow jwt sign against the exact --rpc-resource audience, twice, because the first ones expired at the default five minutes before the server came up.
8. --identity-claim role on the server, without which the Flowfile's signals: claims: {role: customer} rule can never match (#1300).

Once there, everything worked and worked well: alice's runs invisible to bob, a wrong-audience token refused, an anonymous caller refused, a cross-tenant Get denied with an audit record naming the subject, a same-tenant caller without the claim refused at the gate, the entitled caller delivered, and the run completed confirmed: true. The security posture is real. The path to it is the problem, and it is the path every operator walks before their first production deployment and every contributor walks before touching auth/.

Desired outcome

Two small additions and one posture:

• Keys in the file. TrustedIssuer gains jwks_file (a path) and jwks (an inline key set), mutually exclusive with jwks_url, so a rehearsal and an air-gapped deployment need no fetch and no egress section. flow keys public --jwks prints the wrapped document.
• A local issuer posture. flow server dev --auth (or flow auth dev) generates a key under the dev database's directory, writes a trust policy with the inline key, an issuer of its own naming, and namespace_claim: namespace, binds --rpc-resource to its loopback address, and prints the flow jwt sign line that mints a token for a subject and namespace. flow server dev keeps refusing ambient auth configuration; this is a posture it assembles itself and states at start-up like the other three.
• Longer default rehearsal tokens. flow jwt sign defaults to a lifetime that survives standing up a server, with the cap unchanged.

Acceptance criteria

• flow server dev --auth followed by the printed sign command and flow run --token-file completes a run as a named subject in a named namespace, with no web server, no hand-written policy, and no egress section.
• A trust policy with jwks: inline verifies a token with no network, pinned by a test that runs the verifier with a nil egress client.
• docs/DEPLOYMENT.md's recipe starts from the dev posture and shows the diff to a real issuer.

Constraints and dependencies

• Inline keys are for rehearsal and air-gapped deployments; rotation for a jwks entry is a file change and a restart, which the doc says plainly beside #1019's rotation story.
• Adjacent: #1693, #1694, #1300, #110 (flow login and profiles), #557 (human identity), #1649 (flow doctor).

Start with pkg/flowstate/v1/auth/policy.go and the flow keys, flow server dev, and flow jwt sign entry points. Review the acceptance criteria and docs/DEPLOYMENT.md, including the nil-egress verifier test requirement. Done means local authenticated runs work without a web server or egress policy, inline JWKS verifies offline, and the deployment recipe explains the dev-to-real-issuer transition.