[ExtraToast]

Closes #86.

Problem

A native Client signs people in itself, and the model cannot see whether its image enforces that. deploy-kit's E_CLIENT_OPEN (chapter 17) is the proof the release asks for. Before any member is promoted, the gate requests the Client's protected path anonymously, and a 2xx holds the release. The inputs have carried the path since deploy-kit#597, and since deploy-kit#630 also the member that serves it. Nothing asked yet.

Change

• Vendored schemas move to deploy-kit main at 3afe557, with #630: releaseGate.protectedBy beside protectedPath. The generated types follow.
• In may-promote, once the barrier is open and the inputs carry protectedPath, the gate asks protectedBy for it: once, at its Canary service, with no credentials and no redirect followed. The request goes through the analysis traffic from feat(gate): send the gate's own requests to the new copy on each analysis iteration #82.
  • A 2xx holds the release: E_CLIENT_OPEN: <process> serves <path> to anyone (<status>).
  • Any other answer passes, a 401, a redirect or a 404 included: … and <process> refuses <path> to a stranger (<status>).
  • No answer holds the release, because no data is no.
  • A protectedBy member that did not change in the release is not asked: its image was asked when it last did. Its Canary service has no new copy behind it anyway.
• What the gate cannot answer from: inputs that name a path but no member, a member that is not one, a path that is not URL path segments, or a member's Canary with no service port. Each is a 503, with nothing sent.
• Ordering: nothing is asked while the barrier is still shut.
• README. The Release Gate's confirm-promotion row and a new bullet say so.

To know

• No live Application has a native Client yet: they arrive with the identity rollout (deploy-kit#444). Until then no inputs carry protectedPath, and may-promote answers as before.
• TestMayPromote's helper midRelease now takes gate options, so a test can hand it a fake traffic source.

Checks

• New clientopen_test.go:
  • every answer: 401, 302, 404, 200, 204, and no answer, each with the one URL asked, http://auth-api-canary.auth-system.svc.cluster.local:8080/api/me;
  • another member that changed, asked at its own Canary service;
  • a member that did not change, not asked;
  • nothing asked while the barrier is shut;
  • each input the gate cannot answer from.
• go test ./... passes, envtest included; internal/gate is at 97.7% coverage. golangci-lint: 0 issues.