Fleet TLS at scale — Let's Encrypt nip.io registered-domain limit

## Limitation

The workshop issues per-attendee browser-trusted TLS from Let's Encrypt using `nip.io` hostnames. `nip.io` is not on the Public Suffix List, so every `*.nip.io` certificate — across all users globally — counts against the single registered domain `nip.io`, which Let's Encrypt caps at **50 certificate issuances per registered domain per rolling 7 days**. Each attendee's Tier-2 deploy issues one certificate, and teardown does not reclaim budget.

In practice this caps a single event at roughly **12–20 attendees** (well under 50, since the bucket is shared with every `nip.io` user on the internet and retries burn extra), with **no more than one event per rolling 7-day window**. See the "Event capacity" section of the README.

## Proposed approach

Move off the shared `nip.io` bucket onto a maintainer-owned domain:

1. Register a domain and run a self-hosted magic-DNS resolver (e.g. the open-source `sslip.io`) authoritative for a subdomain — it derives the target IP directly from the hostname, exactly like `nip.io`, with zero per-attendee DNS writes.
2. Swap the hostname suffix `.nip.io` for the owned magic-DNS subdomain in `deploy-workshop.sh` (the CloudFormation template and buildspec are unchanged; the certificate is only consumed as an ACM cert on the ALB).
3. File a Let's Encrypt rate-limit override on the owned domain to lift the ceiling for larger cohorts (20–60).

The cert-manager HTTP-01 → ACM-import → ALB flow stays unchanged; only the issuing domain changes.

Read the README's Event capacity section and inspect deploy-workshop.sh to trace how nip.io hostnames enter the certificate flow. Investigate the proposed self-hosted magic-DNS subdomain and the Let's Encrypt rate-limit override requirements. Done means the owned-domain flow supports larger cohorts while the CloudFormation, buildspec, cert-manager, ACM-import, and ALB flow remains unchanged.

Written by the indexing model from the issue text.