[FEATURE]: Attach a static custom header (not just the auth token) to every scan request

Is your feature request related to a problem? Please describe.

Shannon's auth is entirely browser-session based: the preflight drives Playwright and saves a Playwright storageState that downstream agents restore. #453 (and the OAuth-token work sketched there) covers fetching a bearer token from a token endpoint. But two related gaps remain even with a bearer token in hand:

1. A static custom header, distinct from the auth token, that must ride on every request. Some APIs reject a request that carries a valid Authorization: Bearer <jwt> but is missing a second, non-secret header (e.g. X-Source-Client: <value>). This is a constant string, not a credential and not the token — there is no config field for it and storageState cannot express it. token_header/token_prefix from the OAuth work only shape the token's own header.

2. The token issuer is a different origin/service from the target. The token is minted by a login service (a browser form, or a non-standard JSON login endpoint that returns { token, refresh_token } rather than an RFC-6749 access_token body) and is then accepted by separate microservices on other hosts. A Playwright login lands the session on the issuer's origin; it does not carry a header to a different target origin. The OAuth grant_type: password path assumes a standard OAuth token endpoint, which a bespoke JSON login is not.

Net effect: for an API-only target behind (a) a short-lived JWT from a non-OAuth issuer and (b) a mandatory static header, none of form / sso / api / basic fit, and the OAuth work does not close it.

Describe the solution you'd like

Two small, independent additions:

• A config field for extra static request headers (a list of name: value pairs) that agents attach to every request, orthogonal to the auth mechanism. This alone unblocks case (1) for any auth type.
• For case (2): let the token-acquisition step target a non-OAuth JSON login endpoint — a configurable request body plus a JSON path to the token in the response — reusing the same get-oauth-token-style caching/refresh helper (these tokens are often ~5 min while a scan runs ~1–1.5 h, so a single up-front fetch goes stale mid-run).

Which CLI mode does this apply to?

Both

Describe alternatives you've considered

Current workaround: login_type: form plus a login_flow that logs into the issuer, reads the token from localStorage, navigates to the target origin, plants the token there, and a rules_of_engagement instruction telling the agent to attach both the Authorization header and the static header to every request, re-logging in on a 401. It works but is brittle: it leans on the agent reliably applying the headers to each request, and only a live run confirms it.

Additional context

Related to #453 and the OAuth-token design. The static-header need (item 1) is the smaller, higher-leverage piece and is useful independently of any OAuth work.