chore(authz): vendor glaz v2.0.0 protos (S09 Enforcement plan: 2/20)

🎯 What does this MR do?

Bumps the vendored auth/glaz protobuf contract from v1.0.0 to v2.0.0 and regenerates the Go stubs under gen/glaz.

The bump is inert. It adds BatchCheck and its four messages (BatchCheckRequest, CheckItem, BatchCheckResponse, CheckResult) to the descriptor and the generated client, and nothing calls them. The BatchCheck caller lands in step 3, and the first call site in step 19.

This is step 2 of the S09 authorization enforcement plan.

📏 Change size

461 insertions and 50 deletions across 6 files, of which 5 lines are hand-written:

File	+	-	Origin
gen/glaz/service.pb.go	348	37	generated by buf
gen/glaz/service_grpc.pb.go	42	4	generated by buf
third_party/glaz-proto/crates/glaz-proto/service.proto	63	0	synced by vendir
vendir.lock.yml	3	4	written by vendir sync
internal/authz/glaz/metrics.go	3	3	hand-edited (comment only)
vendir.yml	2	2	hand-edited

No executable statement changed anywhere in the diff. The metrics.go edit is entirely inside a doc comment.

🔍 Why the Check path is unaffected

CheckRequest (fields 1-5) and CheckResponse are byte-identical between the two revisions, verified by diffing the upstream v1.0.0..v2.0.0 range restricted to the two vendored protos: the only change across the nine intervening releases is the additive BatchCheck block. v2.0.0's breaking changes are in the Rust FFI surface, not the gRPC service.

The package declaration and the proto/glaz/relationships/relationships.proto import path are unchanged, so the descriptor paths that TestRelationshipsProtoRegistration_DistinctPaths pins do not move and the test needs no edit. The plan flagged that test as the one that might need changing; it does not.

AuthorizationServiceServer gains a method, which would break a non-embedding fake. The only in-repo implementer, fakeAuthz in internal/authz/glaz/client_test.go, embeds UnimplementedAuthorizationServiceServer, so it is unaffected. AR serves no gRPC AuthorizationService in production.

📊 The metrics.go comment

rpcMethods' doc comment enumerated the methods that fall through to the unknown metrics label, and BatchCheck makes that list a member short. Rather than adding a fourth name, the enumeration is replaced with the rule it stood in for, which does not rot as the contract grows, and which tells step 3's author to add the entry alongside the caller. Without it, every BatchCheck RPC would record under rpc="unknown" — a silent metrics gap.

rpcLabel still fails closed to rpcUnknown, so the Prometheus label stays bounded regardless.

✅ Verification

• vendir.yml and vendir.lock.yml pin 4b12eb4abaa92ce960293fff1add8b45e13f1b5c, which is exactly what upstream tag v2.0.0 points at. The pin is the immutable SHA, not the mutable tag.
• All three vendored files (service.proto, relationships.proto, LICENSE) are byte-identical to the raw upstream blobs at that SHA.
• Upstream v2.0.0 also adds crates/glaz-proto/buf.yaml and govern.proto; both fall outside includePaths, and service.proto does not import govern.proto, so their absence is correct.
• mise run proto:generate is a no-op on the committed tree, which is what buf:generate-check gates on.
• go build ./..., the full go test ./... suite, and golangci-lint run ./internal/authz/... (0 issues) all pass.

📦 Deployed sidecar

.runway/fairway.yaml already pins the glaz-sidecar image at v2.0.0, so this bump catches the vendored client contract up to the deployed sidecar rather than the other way around. That satisfies the plan's stated dependency for step 19 ahead of time. Renovate's !1913 (merged) would take the image to v2.1.0, whose service.proto is byte-identical to v2.0.0's.

🧪 Testing

No new tests. The step adds no callable behavior: BatchCheck appears only under gen/glaz/ and is called by nothing. The existing GLAZ client suite passing unchanged is what demonstrates the Check messages are unaltered, and protoregistry_test.go continues to pin the distinct-descriptor-path invariant.

Conformance suites and the e2e scenario catalogs are unaffected: this MR changes no request-serving behavior.

Related issue: #844 (closed)