docs(customer): simplify comments added on this branch

Trim redundant clauses in two comments (governance namespace-scale
benchmark doc, bulk usage-attribution created_at-guard note) that
restated the same point twice or over-qualified it. No behavior change.

Author: gergely-kurucz-konghq

e2e/governance_bench_namespace_test.go

@@ -25,23 +25,21 @@ const (
 // size on governance query latency, independent of the customers/features axes
 // BenchmarkGovernanceQuery already covers. It fixes a small, constant query
 // load (100 customers, matching the OAS customer-key cap, x 1 feature) so the
-// entitlement GetAccess fan-out cost — the dominant cost per
-// BenchmarkGovernanceQuery's doc comment — stays flat across sub-benchmarks,
-// and varies only how many OTHER customers/subjects exist in the namespace
-// (decoys, never queried, seeded directly via SQL for speed, not HTTP).
+// entitlement GetAccess fan-out cost stays flat across sub-benchmarks, and
+// varies only how many other (never-queried) customers/subjects exist in the
+// namespace.
 //
-// This targets the customer usage-attribution resolution path specifically:
-// pre-UNION-ALL, a large decoy count made GetCustomersByUsageAttribution
-// seq-scan the customers table (see #4684 and the follow-up bulk fix); this
-// benchmark shows whether decoy count still moves total request latency
-// post-fix. Decoy counts accumulate across sub-benchmarks (0 -> 10k -> N), so
-// each step only seeds the incremental delta.
+// This targets the customer usage-attribution resolution path: pre-UNION-ALL,
+// a large decoy count made GetCustomersByUsageAttribution seq-scan the
+// customers table (see #4684 and the follow-up bulk fix); this benchmark shows
+// whether decoy count still moves total request latency post-fix. Decoy
+// counts accumulate across sub-benchmarks (0 -> 10k -> N), so each step only
+// seeds the incremental delta.
 //
-// Requires direct Postgres access alongside OPENMETER_ADDRESS (see
-// initE2EPostgresPool) — creating decoys over HTTP would dominate the
-// benchmark's own setup time long before showing anything about the query
-// path. Set GOV_BENCH_NAMESPACE_DECOYS to change the top decoy count from the
-// default 100,000.
+// Decoys are seeded directly via SQL (not HTTP, which would dominate setup
+// time) and require direct Postgres access alongside OPENMETER_ADDRESS (see
+// initE2EPostgresPool). Set GOV_BENCH_NAMESPACE_DECOYS to change the top
+// decoy count from the default 100,000.
 func BenchmarkGovernanceQueryNamespaceScale(b *testing.B) {
 	client := initClient(b)
 	v3 := newV3Client(b)

openmeter/customer/adapter/customer.go

@@ -681,15 +681,13 @@ func (a *adapter) GetCustomersByUsageAttribution(ctx context.Context, input cust
 	return entutils.TransactingRepo(ctx, a, func(ctx context.Context, repo *adapter) ([]customer.Customer, error) {
 		now := clock.Now().UTC()
 
-		// No CreatedAtLTE(now) guard here or in WithSubjects below, deliberately: this keeps the
-		// candidate predicate and the eager-loaded subject list in agreement (both consider every
-		// subject regardless of created_at), matching the single-key
-		// customerMatchesUsageAttributionKey, which has never had this guard. created_at is
-		// server-assigned, immutable, and never caller-supplied (see the ResourceMixin/
-		// CustomerSubjects schema), so a future-created subject cannot occur in production; adding
-		// the guard to only one of the two paths (candidate query vs. eager load) would instead
-		// introduce a real, batch-composition-dependent resolution bug in the caller's per-key
-		// precedence logic for a case that can't happen.
+		// Deliberately no CreatedAtLTE(now) guard here or in WithSubjects below: this keeps the
+		// candidate predicate and the eager-loaded subject list in agreement, matching the single-key
+		// customerMatchesUsageAttributionKey, which never had this guard either. created_at is
+		// server-assigned and immutable (see ResourceMixin/CustomerSubjects schema), so a
+		// future-created subject can't occur in production — guarding only one of the two paths
+		// would instead cause a real, batch-composition-dependent resolution bug for a case that
+		// can't happen.
 		query := repo.db.Customer.Query().
 			Where(
 				customerdb.Namespace(input.Namespace),