fix(gateway): harden inbound auth schema and rename credential flags

[aidandaly24]

Description

Hardens the Custom JWT authorizer schema and renames credential CLI flags for clarity. This is the foundational PR for the Custom JWT gateway feature — it tightens validation and fixes naming before the custom claims feature is added on top.

Schema hardening

• HTTPS enforcement: OidcDiscoveryUrlSchema now rejects http:// URLs via .refine()
• Strict mode: CustomJwtAuthorizerConfigSchema uses .strict() to reject unknown fields
• Flexible constraints: allowedAudience and allowedClients are now individually optional, with a .superRefine() requiring at least one of allowedAudience, allowedClients, or allowedScopes
• deployed-state.ts: Aligned with schema — allowedAudience/allowedClients optional, added allowedScopes

Flag rename (--agent-client-* → --client-*)

These are gateway-level OAuth credentials, not agent credentials. The agent prefix was misleading:

• --agent-client-id → --client-id
• --agent-client-secret → --client-secret
• Updated across: CLI types, validation, GatewayPrimitive, TUI wizard state/handlers/props, useCreateMcp hook

TUI improvements

• HTTPS validation on discovery URL input in the JWT wizard
• Simplified validateCommaSeparated helper (removed unused fieldName param)
• Renamed internal prop names (onAgentClientId → onClientId, etc.)
• Updated prompt labels to remove "Agent" prefix

Test updates

• Schema tests: HTTPS rejection, .strict() rejection, scope-only acceptance, all-empty rejection
• Validation tests: HTTPS check, at-least-one constraint, renamed credential fields
• Integration tests: Updated --agent-client-id/--agent-client-secret → --client-id/--client-secret

Related Issue

Extracted from #596

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[tejaskash]

Code review

Found 1 issue:

1. TUI wizard still forces allowedClients to be non-empty, but the schema and CLI validation now allow it to be optional (only requiring at least one of audience/clients/scopes). The clients sub-step (subStep 2) applies customValidation={validateCommaSeparated} which rejects empty input and lacks the allowEmpty prop, unlike the audience and scopes steps which both have allowEmpty. A user who provides only audience + scopes will be blocked at the clients step.

agentcore-cli/src/cli/tui/screens/mcp/AddGatewayScreen.tsx

Lines 380 to 386 in 460ccf6

	prompt="Allowed Clients (comma-separated, e.g., 7abc123def456)"
	initialValue=""
	onSubmit={onClients}
	onCancel={onCancel}
	customValidation={validateCommaSeparated}
	/>
	)}

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[tejaskash]

Review comments addressed: clients step now allows empty input with allowEmpty prop.