Split claim matching into visibility (OR) and subset (AND)

[rdimitrov]

What

Fixes the multi-value claim bug from #843 by splitting claim matching into two rules by direction:

Rule	Function	Within-array	Used for
Visibility (read)	claimsVisible / validateClaimsVisible[Bytes]	OR — share any one value	per-user entry filter, registry access gate, single-resource GET, delete, source references
Subset (write)	claimsContain / validateClaimsSubset	AND — must hold all values	create / update / publish / update-claims (incoming request claims only)

Both rules now share one key-level matcher (claimsMatch) and differ only in the within-array test.

Why

claimsContain used AND-within-array for every comparison. A resource tagged team: ["platform", "data"] was meant as an allow-list ("platform or data"), but the code required a caller to hold both values — so a user in only platform was filtered out, contradicting the documented OR-within-array rule (auth.md §3). See #843.

The naive fix (flip claimsContain to OR everywhere) would fix reads but open a privilege-escalation hole on writes: a caller could tag a resource with array values they don't fully possess, widening visibility beyond their own identity. Hence the split — visibility is OR, write-subset stays AND.

Behavior change to note

Moving deletes to the visibility rule means anyone who can see a shared-claim resource can also delete it (a caller in one of several allowed groups). This is intentional so list / get / delete agree (auth.md §4), and is documented in the reconciled §5.

Changes

• internal/service/db/claims_filter.go — claimsVisible, validateClaimsVisible[Bytes], shared claimsMatch; claimsContain unchanged in behavior.
• Routed 16 read/access gates to the visibility variants; 7 write sites stay on subset.
• Docs: auth.md §3/§4/§5 rewritten to describe the two rules; data-model.md §4 reconciled.
• Tests: new unit coverage for both rules (incl. AND-across-keys + OR-within-array); fixed the array-claims integration test, which asserted the old AND behavior under an "OR-within-array" title.

Testing

• Unit tests (both matchers, write-path escalation guard, claimsContain requires ALL values of a multi-value claim, contradicting documented OR-within-array semantics #843 scenario) ✅
• Integration tests with real Postgres — internal/service/db + internal/authz ✅, including the end-to-end array-claims test (a platform-only user now correctly sees a team:[platform,data] entry)
• go vet (incl. -tags integration), gofmt, golangci-lint (0 issues) ✅
• Independent security review confirmed no write path on OR and no read gate on AND

Fixes #843

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.15385% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.07%. Comparing base (06a392a) to head (c70a914).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/service/db/impl_registry.go	83.33%	1 Missing ⚠️
internal/service/db/impl_source.go	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #848      +/-   ##
==========================================
+ Coverage   61.97%   62.07%   +0.10%     
==========================================
  Files         109      109              
  Lines       10698    10724      +26     
==========================================
+ Hits         6630     6657      +27     
+ Misses       3483     3482       -1     
  Partials      585      585              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.