CI Failure: harness-custom-jwt E2E rejects-SigV4 test fails with 403 missing audience claim

[aidandaly24]

Summary

The new e2e-tests/harness-custom-jwt.test.ts (added in #1609) fails on the full-suite E2E run, shard 2/5.

• Run: https://github.com/aws/agentcore-cli/actions/runs/28051685327/job/83043643825
• Failing test: rejects SigV4 invocation (auth method mismatch)

Root cause

The test fixture is misconfigured, surfaced by the harness auto-fetch flow that landed in the main+preview merge (#1598, #1611):

1. The harness is deployed with --allowed-audience <clientId>, so the service validates the token's aud claim.
2. The test authenticates via Cognito client_credentials (M2M), whose tokens carry a client_id claim and no aud.
3. The fixture also registers a managed OAuth credential (--client-id/--client-secret), so a default invoke (no --bearer-token) now auto-fetches a JWT instead of doing SigV4 (canFetchHarnessToken() → true).
4. The service rejects the fetched token: 403 \"*** missing required audience claim.\" — which doesn't match the test's expected client-side customJWTRejectMsgRegex.

The sibling byo-custom-jwt.test.ts passes only because it patches agentcore.json with no credential, so it hits the client-side SigV4 fast-fail the regex expects. The same aud misconfiguration is latent there, hidden by a weak not.toMatch assertion.

Fix

• Use --allowed-clients (matches the client_id claim Cognito M2M tokens carry) instead of --allowed-audience.
• Update the deploy assertion to check AllowedClients.
• Reframe the invoke tests to assert the real post-merge behavior (default invoke auto-fetches a JWT and is accepted; bearer-token invoke returns exitCode 0).

This is a test-only fix — no shippable CLI behavior changes.