feat(portal-bff): signed-assertion strategy + /.well-known/jwks.json

Second half of the DownstreamApiClient + OBO chantier per ADR-0014.
Ships the signed-assertion strategy (non-Entra downstreams) and the
JWKS publishing endpoint as testable primitives. The framework
around them (DownstreamApiClientFactory, cockatiel, audience
pre-check, error translation) still waits for the first concrete
integration per the ADR's "until then" clause.

What lands

- assertJwksConfig (config/check-jwks-config.ts):
  - Reads the PEM private key once at boot, refuses missing /
    unreadable / weak material (RSA < 2048, Ed25519, unknown key
    type). Derives the JOSE algorithm (RS256 / ES256 / ES384) from
    the key shape so neither the strategy nor the JWKS controller
    has to re-decide on the hot path.
  - Validates BFF_JWKS_KID against [A-Za-z0-9_-]{4,128} so the
    value lives unescaped in JWT headers + JWKS payloads.
  - Wired in main.ts alongside the other assertX() validators.

- BffSigningKey (downstream/bff-signing-key.ts):
  - Singleton holding { config: JwksConfig, publicJwk: JWK }.
    publicJwk is derived from the private key via `jose.exportJWK`
    on a public KeyObject — no private material leaks through.
  - DI token BFF_SIGNING_KEY wires both consumers (strategy +
    controller) to the same source of truth.

- SignedAssertionStrategy (downstream/strategies/signed-assertion.strategy.ts):
  - Wraps `jose.SignJWT` with the ADR-0014 claim shape: iss,
    sub, aud, audience (workforce|customer), claims (curated
    subset), trace_id, iat, exp.
  - 60 s TTL hard-coded — the ADR mandates it; cache disabled
    because the savings on a 60 s JWT would be marginal and a
    cache would let replayed assertions linger past their TTL.
  - kid header matches the JWKS so a downstream picks the right
    key during rotation.
  - Supports RS256 / ES256 / ES384 transparently — picks the alg
    the validator derived at boot.

- JwksController (downstream/jwks.controller.ts):
  - GET /.well-known/jwks.json returns { keys: [<single jwk>] }.
  - main.ts excludes /.well-known/* from the global /api prefix so
    the route lands at the bare root per RFC 8615.
  - No auth gate (the JWKS is the verification anchor — gating it
    would defeat the purpose). Read-only, so the CSRF middleware's
    GET-exempt path already handles it.

Configuration

- Generate a key:
    mkdir -p apps/portal-bff/.secrets && \
    openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 \
      -out apps/portal-bff/.secrets/jwks.pem
- BFF_JWKS_PRIVATE_KEY_PATH (path to the PEM)
- BFF_JWKS_KID (URL-safe id, 4..128 chars)
- Both mandatory at boot.
- `apps/portal-bff/.secrets/` is matched by the repo's existing
  *.pem / *.key gitignore patterns.

Deps

- jose@^6 added as a direct dep (was transitive). Pinned at the
  workspace root since the BFF is the only consumer today and the
  package isn't part of the Angular bundle graph.
- jest.config.cts: jose ships ESM-only, so its node_modules path
  is removed from transformIgnorePatterns. The pattern walks
  pnpm's deep `.pnpm/` layout — anything under /node_modules/ that
  also contains `jose` somewhere in the path gets transformed.

Tests: +24 specs (env validators 11, signing key 4, strategy 6,
controller 3).

Out of scope (deferred per ADR-0014 "until then"):
- DownstreamApiClientFactory + per-service typed config.
- cockatiel resilience composition.
- Audience pre-check at the call site.
- Error translation tables.
- OTel custom spans `downstream.<service>.<verb>.<path>`.
- The framework wiring that calls SignedAssertionStrategy.sign()
  + attaches the `X-User-Assertion` + ServiceCredential auth
  header to outbound HTTP requests.
- Key rotation (the JWKS lists one key for now; rotation chantier
  adds a second entry + a window-based eviction policy).

These land alongside the first concrete integration so the
framework shape is validated against a real consumer.

apps/portal-bff/.env.example

@@ -114,6 +114,24 @@ SESSION_ENCRYPTION_KEY=replace_with_32_random_bytes_base64url
 #   node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"
 OBO_CACHE_ENCRYPTION_KEY=replace_with_32_random_bytes_base64url
 
+# BFF JWKS signing material (per ADR-0014 §"Service strategy"). The
+# BFF mints short-lived `X-User-Assertion` JWTs to propagate user
+# identity to non-Entra downstreams; downstreams verify the signature
+# against `/.well-known/jwks.json`. Both values are mandatory at boot.
+#
+# Generate an RSA private key:
+#   mkdir -p apps/portal-bff/.secrets && \
+#   openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 \
+#     -out apps/portal-bff/.secrets/jwks.pem
+#
+# RSA-2048 is the minimum the validator accepts; 3072 is the
+# default recommendation. EC P-256 / P-384 also accepted.
+BFF_JWKS_PRIVATE_KEY_PATH=apps/portal-bff/.secrets/jwks.pem
+# Stable key id published in the JWKS + emitted in the JWT `kid`
+# header. URL-safe charset only ([A-Za-z0-9_-], 4–128 chars). Bump
+# this when rotating to a new key.
+BFF_JWKS_KID=bff-2026-05
+
 # Session timeouts (per ADR-0010). Both optional with sensible
 # defaults; override only when staging / prod policy diverges.
 #   SESSION_IDLE_TIMEOUT_SECONDS — sliding window. Each request
@@ -183,8 +201,8 @@ CORS_ALLOWED_ORIGINS=http://localhost:4200,http://localhost:4300
 #   AUDIT_RETENTION_DAYS            (default 365)
 #
 # Downstream API access (ADR-0014):
-#   OBO_CACHE_ENCRYPTION_KEY        — wired (see above, line 113)
-#   BFF_JWKS_PRIVATE_KEY_PATH       (next PR: signed-assertion strategy)
-#   BFF_JWKS_KID                    (next PR: signed-assertion strategy)
-#   <SERVICE>_API_BASE_URL          (per integrated downstream)
-#   <SERVICE>_TIMEOUT_MS            (optional, defaults to 5000)
+#   OBO_CACHE_ENCRYPTION_KEY        — wired
+#   BFF_JWKS_PRIVATE_KEY_PATH       — wired
+#   BFF_JWKS_KID                    — wired
+#   <SERVICE>_API_BASE_URL          (per integrated downstream — lands with the first integration)
+#   <SERVICE>_TIMEOUT_MS            (optional, defaults to 5000 — lands with the first integration)