feat: Reserve every name beneath a wildcard for its project

[scotwells]

Summary

The edge prefers an exact hostname over a wildcard, so a project that could claim one name beneath another project's wildcard would take that name's traffic.

Hostname claims now cover whole subtrees, so a wildcard reserves every name beneath it, at any depth, for the project that holds it.

A later claim beneath another project's wildcard is refused, and so is a wildcard while another project holds a name beneath it, with the refusal naming those hostnames but never the project.

This is behind the certificate service setting, which is off by default, and is stacked on #528.

API

No new fields. A refused hostname reports the reason it already uses for a taken hostname, with a message that says what overlaps.

# Project B adds a name beneath project A's wildcard
status:
  conditions:
    - type: HostnamesInUse
      status: "True"
      reason: HostnameInUse
      message: "Hostnames are already attached to another resource: bucket.s3.example.com"
  hostnameStatuses:
    - hostname: bucket.s3.example.com
      conditions:
        - type: Available
          status: "False"
          reason: InUse
          message: >-
            The hostname "bucket.s3.example.com" is beneath the wildcard
            "*.s3.example.com", which another project has claimed. Taking
            names back from another project is not supported yet; that project
            must remove its wildcard first.

# Project B adds a wildcard while project A serves names beneath it
    - hostname: "*.s3.example.com"
      conditions:
        - type: Available
          status: "False"
          reason: InUse
          message: >-
            The wildcard "*.s3.example.com" cannot be claimed while another
            project serves names beneath it: a.b.s3.example.com,
            photos.s3.example.com. Taking names back from another project is
            not supported yet; that project must remove them first.

Claim	Another project holds	Result
bucket.s3.example.com	*.s3.example.com	refused
a.b.s3.example.com	*.s3.example.com	refused, at any depth
*.s3.example.com	photos.s3.example.com	refused, names listed (first five, then a count)
*.s3.example.com	*.example.com or *.b.s3.example.com	refused
*.s3.example.com	s3.example.com	allowed, since a wildcard does not cover its base
anything	the same project holds the overlap	allowed

Naming hostnames tells the requester which names exist beneath a domain they have already proven they own. Project identities are never shown.

Reclaiming a name from another project is out of scope. Hosted zone claims (datum-cloud/enhancements#917) will define that override for hostnames and zones together, so the refusal says it is not supported yet.

Claims stay one record per hostname on the platform control plane. A wildcard's record is named from a hash of its base, because a record name cannot hold an asterisk, and that name has no dot, so it never collides with an exact hostname's record.

Finding a wildcard above a name is one cached lookup per parent domain. Finding names beneath a wildcard uses an in-memory index of every parent domain of every claim, so no request scans the claims. The index exists only with the setting on.

Claims are rechecked on every pass. When two overlapping claims race past each other's cache, the older one keeps its name and the newer one is released.

Test plan

• Unit tests refuse a later name beneath another project's wildcard, a wildcard over another project's names, and overlapping wildcards, and let one project hold both
• Two claims that raced settle on the older one, and a removed wildcard releases its claim
• Build, vet, lint and the full suite pass locally and in CI
• With the setting off, claims behave as before

Related to datum-cloud/enhancements#913