Inconsistent deployment target handling across CLI commands

[jesseturner21]

Summary

Different CLI commands resolve the --target flag with different fallback strategies, making the CLI unintuitive and unpredictable for users managing multiple deployment targets.

Current Behavior

Command	Default when --target omitted	Multiple targets behavior	Error format when target not found
deploy	Hardcoded 'default'	No error, silently uses 'default'	Simple "not found"
invoke	Hardcoded 'default'	Uses first deployed target	Shows available target list
status	First available target	Uses first available target	Shows available target list
import	'default' fallback	Errors, requires --target flag	Formatted multi-line list

Specific code locations

Defaults to hardcoded 'default' string:

• src/cli/commands/deploy/command.tsx:156 — target: cliOptions.target ?? 'default'
• src/cli/commands/invoke/command.tsx:155 — targetName: cliOptions.target ?? 'default'
• src/cli/commands/import/actions.ts:484 — const targetName = target?.name ?? 'default'

Defaults to first available (different strategy):

• src/cli/commands/status/action.ts:225 — options.targetName ?? targetNames[0]
• src/cli/commands/invoke/action.ts:45 — options.targetName ?? targetNames[0]!
• src/cli/operations/resolve-agent.ts:70 — targetNames[0]!

TUI vs CLI divergence

• Deploy TUI (src/cli/tui/hooks/useAwsTargetConfig.ts) allows multi-target selection; CLI only accepts one
• Status TUI (src/cli/tui/screens/status/useStatusFlow.ts) allows cycling through targets; CLI shows only one
• Import has no TUI mode at all

Expected Behavior

All commands should use a single, consistent target resolution strategy:

1. If --target specified → validate it exists and use it
2. If exactly one target exists → use it automatically
3. If multiple targets exist and no --target specified → error with a list of available targets
4. Error messages should use the same format across all commands

Proposed Solution

Create a shared resolveTarget() utility that all commands call, replacing the per-command ad-hoc logic. This would be a single source of truth for target resolution with consistent error handling.

Impact

Users with multiple deployment targets (e.g., staging + prod) get different behavior depending on which command they run, which is confusing and can lead to accidentally operating on the wrong target.