feat: add API Gateway target TUI wizard and address review feedback

[aidandaly24]

Description

Adds the TUI wizard flow for API Gateway targets, along with review feedback fixes and polish from CLI #509.

TUI Wizard:

• New target type option: "API Gateway REST API" in the target type picker
• Three new wizard steps: REST API ID, Deployment Stage, Tool Filters (split into two prompts: path pattern + HTTP methods)
• apiGateway step sequence: name → target-type → rest-api-id → stage → tool-filters → gateway → confirm
• Wizard navigation refactored from hardcoded setStep() to dynamic goToNextStep() for all setters except setTargetType (closure issue documented)
• ConfirmReview shows apiGateway-specific fields (REST API ID, Stage, Tool Filters) instead of Endpoint/Outbound Auth
• Flow dispatches to createApiGatewayTarget() for apiGateway targets

ResourceGraph:

• Shows restApiId/stage and [apiGateway] badge for API Gateway targets

Review Feedback Fixes (from CLI #2 review):

• Made sourcePath, host, toolDefinition, description, language optional on AddGatewayTargetConfig — apiGateway targets don't use these
• Removed dummy field values from apiGateway CLI dispatch config
• Removed unused targetType from dispatch config (method hardcodes it)
• Added outboundAuth rejection to schema superRefine for apiGateway targets
• Moved apiGateway validation block before outbound auth validation to prevent misleading errors
• Fixed success screen: no "Project created at " for apiGateway, showDevOption={false} for gateway targets

Related Issue

Closes #

Documentation PR

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

Additionally:

• Manually tested TUI wizard end-to-end: selected API Gateway REST API, entered REST API ID, stage, tool filters, gateway, confirmed — correct mcp.json written
• Verified remove + re-add via TUI works correctly
• 1978 unit tests pass, zero regressions

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.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	42.74%	3722 / 8707
🔵	Statements	42.34%	3927 / 9274
🔵	Functions	44.39%	737 / 1660
🔵	Branches	44.76%	2426 / 5420

Generated in workflow #899 for commit 512eec3 by the Vitest Coverage Report Action

[tejaskash]

Code Review

1. Non-null assertion (!) proliferation — 8 new instances (Medium)

Making fields optional on AddGatewayTargetConfig and then using ! at every call site trades one problem (dummy values) for another (suppressed type safety). There are 8 new ! assertions across GatewayTargetPrimitive.ts (config.toolDefinition! ×2, config.sourcePath! ×4, config.language! ×1) and useCreateMcp.ts (config.language! ×1).

If a code path ever reaches these without the field set (e.g., a new target type that doesn't set sourcePath), it'll be a silent undefined runtime error. A discriminated union would be the proper fix:

type AddGatewayTargetConfig = 
  | { targetType: 'apiGateway'; name: string; restApiId: string; stage: string; ... }
  | { targetType: 'mcpServer'; name: string; sourcePath: string; language: TargetLanguage; host: ComputeHost; toolDefinition: ToolDefinition; ... }

Worth tracking before adding more target types.

---

2. Tool filter HTTP methods are not validated in the TUI (Medium)

In AddGatewayTargetScreen.tsx (lines ~233-238), user input is split, trimmed, and uppercased, but never validated against the allowed set (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS). If a user types GET,TRACE, the value TRACE will be written to the config and only fail at deploy time when the Zod schema (ApiGatewayHttpMethodSchema) rejects it. Consider validating in the wizard or using a multi-select instead of free-text input.

---

3. outboundAuth schema check allows type: 'NONE' (Low)

In mcp.ts line 360, the check is data.outboundAuth && data.outboundAuth.type !== 'NONE'. This means { outboundAuth: { type: 'NONE' } } is technically valid on an apiGateway target. If outbound auth is "not applicable" for apiGateway, all values should be rejected, not just non-NONE. Consider simplifying to if (data.outboundAuth).

---

4. Two-phase tool-filters step uses component-local state (Low)

In AddGatewayTargetScreen.tsx, the tool-filters step is split into two prompts (path pattern → HTTP methods) managed by a local filterPath state variable, creating a sub-step outside the wizard's step tracking. The wizard's step value stays at 'tool-filters' throughout both sub-prompts. This works but is fragile — if more sub-steps are needed later, this pattern doesn't scale. Consider promoting these to separate wizard steps (tool-filter-path, tool-filter-methods).

---

5. Triple-nested ternary in ResourceGraph (Nit)

In ResourceGraph.tsx (lines ~247-252), the displayText computation is now a three-level ternary, duplicated at line ~292. Consider extracting a helper:

function getTargetDisplayText(target: AgentCoreGatewayTarget): string {
  if (target.targetType === 'mcpServer' && target.endpoint) return target.endpoint;
  if (target.targetType === 'apiGateway' && target.apiGateway)
    return `${target.apiGateway.restApiId}/${target.apiGateway.stage}`;
  return target.name;
}

[aidandaly24]

@tejaskash I will fix #3 in the next PR for auth