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`

Beginne mit cdk/src/bootstrap/policies/ und cdk/src/constructs/registry.ts:90-104 und vergleiche dabei den Richtlinienumfang der deploy-role mit der Rolle der custom resource Lambda. Führe die beiden grep-Befehle aus dem Issue aus und lies anschließend cdk/test/bootstrap/synth-coverage.test.ts, um die Zuordnung von Ressourcen zu Aktionen zu verstehen. Als erledigt gilt die Aufgabe, wenn die beabsichtigte Zuständigkeit geklärt ist und entweder die erforderlichen Aktionen abgedeckt sind oder der Ausschluss dokumentiert ist und das Coverage-Verhalten bei Bedarf behandelt wurde.

Vom Indexierungsmodell aus dem Issue-Text verfasst.