fix: auto-detect host SA from metadata + accept default Compute SA

[ptone]

Summary

• Co-located broker registration (registerGlobalProjectAndBroker) never set gcpHostServiceAccountEmail, causing GCP identity passthrough to fail on the single-node tier
• Auto-detect host SA email and project ID from GCE metadata server during broker registration (both create and update paths)
• Widen isValidServiceAccountEmail() to accept @developer.gserviceaccount.com (default Compute Engine SA format)

Changes

• cmd/server_broker.go: detect SA from metadata.Email("default") and metadata.ProjectID() (+43/-8)
• pkg/hub/passthrough_gate.go: accept @developer.gserviceaccount.com in validator (+20/-15)
• pkg/hub/passthrough_gate_test.go: comprehensive tests for validator and detection (+111)

Test plan

• All hub tests pass
• New tests cover: valid IAM SAs, valid default Compute SAs, invalid domains, edge cases
• Metadata detection tested via existing metadata package mocks

Tracking: ptone#1450

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces auto-detection of the GCP host service account and project ID from the GCE metadata server during broker registration, and expands service account email validation to support default Compute Engine service accounts (@developer.gserviceaccount.com). Feedback suggests ensuring GCPHostProjectID is explicitly validated when using developer service accounts, as the project ID cannot be parsed from the project number in the email. Additionally, a code suggestion was provided to also support App Engine default service accounts (@appspot.gserviceaccount.com).

[gemini-code-assist]

For @developer.gserviceaccount.com service accounts, the project ID cannot be derived from the email address because the email contains the project number (e.g., 721899303052-compute), not the project ID (alphanumeric string), and the domain does not encode the project ID.

If GCPHostProjectID is left empty, the fallback projectIDFromServiceAccountEmail (called on line 158) will fail to extract a valid project ID, leading to failed GCP IAM checks.

Consider adding a validation check in the broker update/registration path to ensure GCPHostProjectID is explicitly provided when a @developer.gserviceaccount.com service account is used, or update projectIDFromServiceAccountEmail to explicitly handle or fail for this domain.

[gemini-code-assist]

While adding support for @developer.gserviceaccount.com is great for default Compute Engine service accounts, another very common default GCP service account domain is @appspot.gserviceaccount.com (used as the App Engine default service account, which has the format {project-id}@appspot.gserviceaccount.com).

Consider also accepting appspot.gserviceaccount.com in this switch to support environments using the App Engine default service account.

	switch {
	case strings.HasSuffix(domain, ".iam.gserviceaccount.com"):
		// Custom IAM SA: project ID portion must be non-empty.
		projectID := domain[:len(domain)-len(".iam.gserviceaccount.com")]
		return len(projectID) > 0
	case domain == "developer.gserviceaccount.com":
		// Default Compute Engine SA (e.g. <project-number>-compute@developer.gserviceaccount.com).
		return true
	case domain == "appspot.gserviceaccount.com":
		// App Engine default SA (e.g. <project-id>@appspot.gserviceaccount.com).
		return true
	default:
		return false
	}