fix(bootstrap): least-privilege policies grant no agent-registry actions — deliberate exclusion or coverage gap?

**Component:** cdk (bootstrap policies)

## Describe the bug

The least-privilege bootstrap policies grant no `agent-registry:*` actions at all, even though the stack creates an `AWS::CloudFormation::Stack` containing a `Custom::AgentRegistry` resource whose backing registry is a real, billable AWS resource.

```
$ grep -rc 'agent-registry' cdk/src/bootstrap/policies/
0
```

Nothing is broken today, which is why this has gone unnoticed: the registry's control-plane calls (`CreateRegistry`, `GetRegistry`, `UpdateRegistry`, `DeleteRegistry`) run under the custom resource's **Lambda execution role**, granted at `cdk/src/constructs/registry.ts:90-104` — not under the CloudFormation execution role the bootstrap policies scope.

The question is whether that's the intended design. If deploy-role coverage is meant to span every resource type the stack creates, this is a gap. If routing resource creation through a custom resource's own role is an accepted pattern for preview services, it's worth saying so explicitly, because the asymmetry currently reads as an oversight.

## Expected behavior

One of:

1. The bootstrap policies cover `agent-registry` actions, consistent with every other resource type the stack provisions; or
2. A comment in `cdk/src/bootstrap/policies/` (or `docs/design/DEPLOYMENT_ROLES.md`) records that custom-resource-provisioned services are deliberately out of scope for the deploy role, and why.

## Current behavior

No `agent-registry` actions anywhere in `cdk/src/bootstrap/`. A reader auditing the deploy role against the synthesized template finds a resource type with no corresponding grant and no explanation.

## Reproduction steps

```bash
grep -rn 'agent-registry' cdk/src/bootstrap/ # no hits
grep -n 'agent-registry' cdk/src/constructs/registry.ts # grants on the Lambda role instead
```

## Possible solution

Decide which of the two above is intended, then either add the actions or document the exclusion. Worth checking at the same time whether `cdk/test/bootstrap/synth-coverage.test.ts` can be taught to notice this class of gap — it currently maps CloudFormation resource types to required actions, and a `Custom::` resource whose real work happens under a different role is exactly the case it cannot see.

## Notes

Found during review of [#868](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/pull/868) by @isadeks, who confirmed via `git log -S` that it is pre-existing and untouched by that diff, so it was deliberately kept off that PR.

Related: [#865](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/issues/865) — the same bootstrap policies also fail to authorize nested-stack resources, because they scope every ARN to the `backgroundagent-dev-*` prefix that nested-stack physical names do not carry. Both are bootstrap-coverage gaps found the same way and may be worth resolving together.

## Environment

- Commit `e96dc21e`

Start with cdk/src/bootstrap/policies/ and cdk/src/constructs/registry.ts:90-104, comparing the deploy-role policy scope with the custom resource Lambda role. Run the two grep commands in the issue, then read cdk/test/bootstrap/synth-coverage.test.ts to understand its resource-to-action mapping. Done means the intended ownership is established and either the required actions are covered or the exclusion is documented, with coverage behavior addressed if appropriate.

Written by the indexing model from the issue text.