perf(people): forbid redirect-following in Employment-separation buyer evidence #393

Finding

Draft #317 currently uses http.post(...) / http.batch(...) without a request-scoped redirects override. Pinned k6 v2.2.0 initializes ParsedHTTPRequest.Redirects from the global MaxRedirects, and the default k6 behavior follows redirects. The returned Response represents the final request after redirects.

That creates a commercial-evidence false-GREEN: /v1/employment-separations can redirect and a later endpoint can return the expected 200/409 JSON/privacy envelope, while #317 records the final response and latency as if the canonical People route itself produced the governed result. Redirect traffic can also alter request-rate accounting and make the measured buyer path differ from the route under test.

Required repair

• Test first: request policy must fail closed unless redirects === 0 for every single and contention request.
• Apply the same request policy to first_commit, replay, rejection and both http.batch contention requests.
• Do not rely on global runner configuration; use request-scoped policy so the workload contract is self-contained.
• Preserve current auth/idempotency headers, direct-network requirement, response privacy/media-type contracts, cardinality and latency evidence.
• Keep test(perf): add Employment separation buyer-path workload #317 Draft until protected/integration and authenticated performance-attestation conditions are satisfied.

Primary evidence

• Pinned k6 v2.2.0 js/modules/k6/http/request.go: ParsedHTTPRequest.Redirects defaults to state.Options.MaxRedirects, while request parameter redirects overrides it.
• Grafana k6 HTTP documentation: redirects are followed by default; Params.redirects overrides maxRedirects per request; final Response information pertains to the last request in a redirect chain.

Owner: #317 / #316 performance acceptance lane. This issue is not complete on branch-local repair alone.