MyHarness CUSTOM_JWT authorizer conflicts with SigV4-only /chat transport (403 error)

### Problem

Loading `/chat` on a deployed sandbox fails with:

\`\`\`
Error: AgentCore error 403: {"message":"This harness requires OAuth Bearer token authentication."}
\`\`\`

### Root cause

\`web/lib/agentcore-transport.ts\` SigV4-signs every \`/harnesses/invoke\` request using IAM credentials from the Cognito Identity Pool (\`signedFetch()\`, agentcore-transport.ts:11-49).

But the deployed \`MyHarness\` is configured with a JWT Bearer authorizer, not IAM:

\`\`\`json
// agent/default/app/MyHarness/harness.json
"authorizerType": "CUSTOM_JWT",
"authorizerConfiguration": {
"customJwtAuthorizer": {
"discoveryUrl": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_qG5061DTr/.well-known/openid-configuration",
"allowedClients": ["2hugv1ugrni8jts323q1ldiopt"]
}
}
\`\`\`

\`AgentCoreApplication\` (\`web/amplify/constructs/agentCoreApplication.ts:199-208\`) forwards this verbatim into the \`CfnHarness\`'s \`authorizerConfiguration\`. Once a harness has a \`customJwtAuthorizer\` configured, AgentCore requires every \`/harnesses/invoke\` call to carry a Bearer JWT and rejects SigV4/IAM-signed requests outright.

Two compounding issues:
1. **Auth mode mismatch** — the harness wants CUSTOM_JWT, the frontend transport only sends SigV4/IAM.
2. **Even if JWT auth is the intended mode**, \`discoveryUrl\`/\`allowedClients\` are hardcoded to a fixed user pool/client (\`us-east-1_qG5061DTr\` / \`2hugv1ugrni8jts323q1ldiopt\`) from a stale prior deployment, not the current branch's sandbox pool. Contrast with \`AgentCoreRuntimeWithBuild\` (used for the AGUI runtime), which correctly derives \`cognitoDiscoveryUrl\`/\`allowedClients\` from \`backend.auth.resources.userPool*\` at synth time (\`backend.ts:121-127\`) — \`AgentCoreApplication\` never does this for \`MyHarness\`.

This predates PR #30 (the \`authorizerType: CUSTOM_JWT\` block was added in commit \`2ce53da\`) but PR #30 carried it forward into the new same-stack \`CfnHarness\` without reconciling it against the SigV4 transport.

### Likely misclassified as unrelated

The e2e suite's \`chat.spec.ts\` "agent returns a response after sending a message" test has been failing with an agent-response timeout across several sessions on PR #30, dismissed as a "pre-existing/unrelated" flake. It almost certainly is this same 403/auth mismatch, just never root-caused.

### Suggested fix

Either:
- Drop the \`customJwtAuthorizer\` config from \`harness.json\` / \`AgentCoreApplication\` so the harness accepts IAM/SigV4 (matching the current frontend transport), or
- Switch \`web/lib/agentcore-transport.ts\` to send a Cognito JWT bearer token instead of SigV4, and fix \`AgentCoreApplication\` to derive \`discoveryUrl\`/\`allowedClients\` from the live \`backend.auth\` resources instead of a hardcoded stale pool/client.

This is being tracked separately from #142/PR #30 per waltmayf's request to file issues for bugs found during that PR.

---
*Imported from `waltmayf/agentcore-amplify-fullstack`#53 — originally filed by @app/github-actions on 2026-07-06. Migrated to open-source repo; cross-references updated post-import.*

Read web/lib/agentcore-transport.ts and web/amplify/constructs/agentCoreApplication.ts, then compare the authorizer setup with backend.ts:121-127. Run the e2e chat.spec.ts test and confirm the /chat request's 403 cause. Done means the harness and transport use a consistent authentication mode, live authorizer configuration is used where applicable, and the chat test receives an agent response.

Written by the indexing model from the issue text.