Inconsistent deployment target handling across CLI commands

## 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.