CLO-117: reject AWS PrivateLink SERVICE NAME that is not a service name

[jubrad]

Fixes CLO-117.

Motivation

A user created an AWS PrivateLink connection with an ELB DNS hostname in
SERVICE NAME instead of a VPC endpoint service name:

CREATE CONNECTION c TO AWS PRIVATELINK (
  SERVICE NAME 'my-db-lb-0123456789abcdef.elb.eu-central-1.amazonaws.com',
  AVAILABILITY ZONES ()
);
-- CREATE CONNECTION

CREATE CONNECTION accepted it, and the mistake only surfaced later as

Error: The Endpoint cannot be created due to missing availability zones

which points at the wrong option. The environment controller cannot parse that
value as a cross-region service name, so it treats the endpoint as same-region
and reports the empty AVAILABILITY ZONES list as the failure.

Changes

• AwsPrivatelinkConnection::check_service_name rejects values that cannot be
  AWS VPC endpoint service names. It is deliberately permissive: it requires
  only the com.amazonaws. prefix, so both customer-owned
  (com.amazonaws.vpce.<region>.vpce-svc-<id>) and AWS-managed
  (com.amazonaws.<region>.<service>) services pass.
• A new PlanError::InvalidPrivatelinkServiceName carries a hint that gives the
  expected shape and says the value is not the DNS name of the target.
• CREATE CONNECTION and ALTER CONNECTION now fail up front with that error.
• AwsPrivatelinkConnection::validate performs the same check before reading
  endpoint status, so VALIDATE CONNECTION on a connection that already stores
  an offending value reports the true cause instead of the availability zone
  message. This is the exact symptom in the report, and it also removes the need
  for a new VpcEndpointState variant in the cloud repo.
• Docs: the SERVICE NAME syntax element now says what the value is and is not.

Why the sequencer and not the planner

The obvious home for this is plan_connection, next to the existing
AVAILABILITY ZONES validation. That is not safe. Catalog items are re-planned
on boot via CatalogState::deserialize_item, and a failure there panics
(src/adapter/src/catalog/apply.rs). Any environment that already stores an
offending service name would crash-loop on upgrade, which is precisely the
population this change is about. with_enable_for_item_parsing does not help
either, since it force-enables flags during item parsing, so a flag-gated
planner rule would still fire on boot.

The sequencer runs only for statements a client issues, so the rule cannot stop
an existing item from loading. For CREATE the check precedes id allocation,
secret creation, resource-limit validation, and the catalog transaction, so
nothing leaks before the rejection.

Two accepted behavior changes for environments that already store an offending
value:

• CREATE CONNECTION IF NOT EXISTS with the offending name now errors instead
  of being a no-op. This matches how existing option validation already behaves
  (an invalid AVAILABILITY ZONES entry errors at plan time regardless of
  IF NOT EXISTS).
• ALTER CONNECTION re-plans the full create_sql, so it reports the stored
  offending name even when the statement does not touch SERVICE NAME. Setting
  a valid SERVICE NAME in the same ALTER clears it.

Tips for reviewer

The permissiveness of the rule is the main thing to sanity check. It is
prefix-only on purpose. Worth confirming with the cloud team that no live
connection uses a service name outside com.amazonaws.* before this ships,
since such a connection would start failing VALIDATE CONNECTION and ALTER.

Checklist

• This PR has adequate test coverage / QA involvement has been duly
  considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:
  • CREATE CONNECTION ... TO AWS PRIVATELINK and ALTER CONNECTION now reject
    a SERVICE NAME that is not an AWS VPC endpoint service name, and
    VALIDATE CONNECTION reports that as the cause instead of a missing
    availability zone.

🤖 Generated with Claude Code