fix: never restore over or destroy an operator-pinned aurora cname

[vigneshrajsb]

Description

• An aurora-restore deploy only skipped restore while its status was BUILT or READY. Any other status (a superseded run left QUEUED, a failed rollout, a teardown) fell through to the tag lookup and, finding nothing, ran a full restore. That replaced a hand-set cname with the endpoint of a brand-new cluster.
• This bites environments that point an Aurora service at an externally managed database, for example a DNS record that follows a blue/green refresh job. The override silently reverts and a duplicate cluster is left running.
• A cname that isn't an RDS endpoint is now treated as pinned by an operator: Lifecycle only ever stores endpoints returned by AWS, so anything else was set by hand. Pinned cnames skip restore regardless of status, and are never overwritten.
• Targeted teardown and full build deletion skip the CLI destroy for pinned cnames, so Lifecycle never deletes a database it didn't create.
• Deploys with no cname, or an RDS endpoint cname, behave exactly as before.

Verifying Changes

• jest full suite and eslint on the changed files: both green. tsc reports no new errors in the touched files.
• New tests cover the pinned check (case, trailing dot, China-region RDS suffix), restore skipped from QUEUED / DEPLOY_FAILED / ERROR / TORN_DOWN, and teardown and build deletion leaving a pinned database in place while still destroying a Lifecycle-restored one.

Notes

• Pinning is inferred from the hostname, so a raw *.rds.amazonaws.com endpoint set by hand is not protected and keeps today's behavior. The workaround is to front it with a DNS name. An explicit pin flag is a possible follow-up if pinning raw endpoints turns out to be common.