docs(request-validation): note auth-invalid also overrides header rendering

The headersAuth field doc only flagged auth-deny as rendering its own
Authorization header despite headersAuth:false. auth-invalid does too (a
well-formed header with an invalid/unknown credential). Generalize the note to
cover both kinds.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: esraagamal6

request-validation/src/model/types.ts

@@ -140,10 +140,14 @@ export interface ValidationScenario {
   description: string;
   /**
    * Whether to send the configured *admin* credentials, i.e. authHeaders()
-   * (multipart) / jsonHeaders() (JSON). false → no headers ({}).
-   * NOTE: this flag does not govern `auth-deny` scenarios — those always
-   * authenticate as the zero-grant probe user via denyProbeHeaders() (a
-   * different principal) regardless of this value, which they leave false.
+   * (multipart) / jsonHeaders() (JSON). false → no admin credentials.
+   * NOTE: some scenario kinds render their own `Authorization` header
+   * regardless of this flag (which they leave `false`):
+   *   - `auth-deny` authenticates as the zero-grant probe user via
+   *     denyProbeHeaders() (a different principal);
+   *   - `auth-invalid` sends a well-formed header carrying an invalid/unknown
+   *     credential (`Bearer invalid-token`).
+   * For all other kinds, `false` → no headers (`{}`).
    */
   headersAuth: boolean;
   source?: 'body' | 'query' | 'path' | 'header' | 'cookie';