feat(cdk): tag-safe strategy — exclude replacement-sensitive resources from volatile github:* tags

## Problem

All `github:*` tags change on every deployment (`sha`, `run-id`, `actor`, etc.). Some CloudFormation resource types treat **any tag change** as requiring replacement (new physical resource ID). When a replaced resource has dependents with uniqueness constraints (e.g., Route53 Resolver VPC association), the cascade fails and corrupts the CloudFormation state — requiring manual intervention to recover.

**Incident history:**
- PR #211 / #221: `CfnResolverQueryLoggingConfig` tag update → replacement → Association fails on VPC uniqueness → stack stuck in `UPDATE_ROLLBACK_COMPLETE`
- Current deploy: Association still references stale Config ID from prior failed replacement

## Desired outcome ("no touch needed")

Deploys should never fail due to tag propagation triggering resource replacement. The solution should be self-maintaining — new resources added to the stack should be automatically protected without manual discovery.

## Options

### Option A: CDK Aspect that auto-excludes replacement-sensitive resources (Recommended)

Create a custom Aspect that runs at synth time and inspects each `CfnResource`. If the resource's CloudFormation spec indicates that tags require replacement (`Update requires: Replacement` on the `Tags` property), auto-exclude it from tagging.

**Pros:** Self-maintaining, no manual denylist, protects future resources automatically.
**Cons:** Depends on CloudFormation Resource Spec accuracy (some resources don't report correctly).

### Option B: Reactive denylist with synth-time validation (Fallback)

Maintain `excludeResourceTypes` array (current approach), but add a synth-time check: a CDK Aspect that warns or fails if a tagged resource is known to treat tags as replacement. Build the denylist from:
1. Known problematic types (Route53Resolver, etc.)
2. CloudFormation Resource Spec where available
3. Discovered failures added incrementally

**Pros:** Simple, explicit, doesn't rely on spec accuracy.
**Cons:** Reactive — new problematic types discovered via deploy failures.

### Option C: Hybrid (A + B)

Use the Aspect from Option A as the primary gate, with an explicit denylist (Option B) as override for resources where the spec is inaccurate or missing. Log warnings at synth time when a resource is excluded by either mechanism.

## Immediate fix needed

Add `AWS::Route53Resolver::ResolverQueryLoggingConfigAssociation` to the existing `excludeResourceTypes` array to unblock deploys. Then comment out the Association, deploy (clears CF state), uncomment, redeploy (fresh creation).

## Acceptance criteria

- [ ] Deploys with changed `github:*` tags never trigger resource replacement
- [ ] New replacement-sensitive resources are automatically detected (Aspect or CI check)
- [ ] Existing broken CF state is recovered (one-time manual fix documented)
- [ ] Approach handles resources where CloudFormation spec doesn't accurately report replacement behavior

## References

- PR #211: Per-session IAM scoping (introduced tags on all resources)
- PR #221: Excluded `CfnResolverQueryLoggingConfig` from tags
- [CloudFormation Resource Spec](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-resource-specification.html)
- `cdk/src/main.ts` lines 45-67: tag application logic

Commencez dans cdk/src/main.ts, aux lignes 45-67, pour comprendre l’application actuelle des tags et la logique de excludeResourceTypes. Lisez la CloudFormation Resource Spec et comparez son comportement de remplacement des tags avec celui des ressources resolver mentionnées dans l’issue. C’est terminé lorsque l’exclusion de l’association immédiate est ajoutée, que les ressources sensibles au remplacement sont détectées automatiquement ou validées au moment du synth, et que la procédure de récupération ponctuelle est documentée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.