Scope Gateway Target names to their parent Gateway

### Description

Gateway Target names should be unique within their parent Gateway, matching the
AgentCore service contract, rather than unique across an entire CLI project.

Today the CLI effectively requires project-global Target names because the L3
construct emits Target outputs using only the Target name:

```text
GatewayTargetId
```

The old CLI's CloudFormation output parser also expects that format. As a result,
two Gateways cannot both have a naturally named Target such as `search`, even
though the service permits it.

Change the L3 output contract to include the parent Gateway:

```text
TargetId
```

The CLI should enforce uniqueness only inside each Gateway. During the
transition, the old CLI output parser should accept both the existing
Target-only format and the new Gateway-qualified format so existing deployed
stacks continue to work.

This was intentionally deferred from aws/agentcore-cli#2028 to keep that PR
compatible with the currently published L3 output contract.

### Acceptance Criteria

- [ ] Two different Gateways in one project can each contain a Target with the same name.
- [ ] Duplicate Target names within one Gateway are still rejected.
- [ ] L3 Target output logical IDs and export names include both Gateway and Target names.
- [ ] The old CLI CloudFormation output parser accepts both legacy `GatewayTargetId` and new `TargetId` outputs.
- [ ] Output parsing associates each Target ID with the correct parent Gateway when names are duplicated.
- [ ] Existing projects and stacks using legacy output names continue to deploy and update.
- [ ] CLI schema, command, L3 synthesis, output-parser, and deployment-state tests cover cross-Gateway duplicate names.
- [ ] The project-based refactor removes its temporary project-global Target-name validation after the compatible L3 version is published.

### Additional Context

This requires coordinated changes in:

- `aws/agentcore-l3-cdk-constructs` for Gateway-qualified outputs;
- the old CLI output parser and deployment-state mapping;
- the project-based refactor's Target uniqueness validation.

Start with the CLI schema, L3 synthesis, output-parser, deployment-state mapping, and project-based Target validation named in the issue. Trace how Gateway and Target names become logical IDs and how legacy outputs are associated with Gateways. Done means duplicate Target names work across Gateways, remain rejected within one Gateway, both output formats parse, and the listed tests cover compatibility.

Written by the indexing model from the issue text.