feat(werkbank): runner queue endpoints + result persistence (WB-05)

The control-plane side of the pull API (implements sharang/werkbank#6), so a
Werkbank runner can reach a real queue end-to-end:

- POST /api/v1/werkbank/jobs/{lease,heartbeat,complete} — thin handlers over the
  JobQueue (WB-02), tenant-scoped from the request's `tenant` (db_pool
  .for_tenant_id). lease→204 when empty; heartbeat→409 on a lost lease.
- Machine auth: a static WERKBANK_RUNNER_TOKEN bearer (require_runner_token),
  mounted only when the token is set — like the admin API, and NOT a Keycloak JWT
  (a runner acts across tenants). /api/v1/werkbank/* is added to the JWT
  PUBLIC_PREFIXES so it routes to the runner-token gate, not the customer-JWT one.
- On completion, the runner's findings + DAST findings are persisted against the
  job's target (dedup'd by fingerprint), so a job run by a remote runner lands
  the same findings an in-process run would.
- Shared transport types (LeaseRequest/HeartbeatRequest/CompleteRequest/
  CompleteResponse) live in compliance-core so the runner (client) and control
  plane (server) agree on shapes.

Tests: 3 HTTP integration tests against a live Mongo (lease→complete→persist,
empty-queue 204, and the bearer-token gate) + a token-compare unit test. Skips
cleanly with no Mongo. clippy + fmt clean.

Follow-up: wiring the scan pipeline to enqueue plc-provision jobs needs an
artifact-fetch path for the runner (so it can pull the program blob); tracked
with the on-prem work.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

compliance-core/src/auth.rs

@@ -64,11 +64,11 @@ struct Claims {
 const PUBLIC_ENDPOINTS: &[&str] = &["/api/v1/health"];
 
 /// Path prefixes that bypass JWT validation. The admin sub-router
-/// (`/api/v1/admin/*`) has its own static-bearer middleware and must
-/// not be routed through the customer-JWT path — a Keycloak token
-/// always carries a single tenant_id and would semantically conflict
-/// with cross-tenant admin operations.
-const PUBLIC_PREFIXES: &[&str] = &["/api/v1/admin/"];
+/// (`/api/v1/admin/*`) and the Werkbank runner API (`/api/v1/werkbank/*`)
+/// have their own static-bearer middleware and must not be routed through the
+/// customer-JWT path — a Keycloak token always carries a single tenant_id and
+/// would semantically conflict with these cross-tenant / machine operations.
+const PUBLIC_PREFIXES: &[&str] = &["/api/v1/admin/", "/api/v1/werkbank/"];
 
 /// Middleware that validates Bearer JWT tokens against Keycloak's JWKS
 /// and attaches a `TenantContext` extension on success.