feat(maven): resolution holder and shared resolver part 1/2 (S09 Enforcement plan: 9/20)

Split into 2 stacked MRs to keep each within the review size limit (~800 LoC ideal). Each part targets the previous one (part 1 targets main); review and merge bottom-up.

Part 1 of 2 of S09 authorization enforcement — Step 9: Maven wiring.

What this part adds

The format-package foundation plus the composition-root refactor the wiring in part 2 builds on — no authorization behavior changes yet; mountSlugAnchoredFormats still consults no gate:

  • internal/format/maven/context.go: the package's resolution holder, in the shape internal/namespace/context.go uses — an installed mutable cell, a setter panicking on a missing holder and on a zero MavenRepositoryID or a zero RepositoryID (a zero maven.Resolution reads as hosted-and-unsuspended, so it would fail open on both write gates; RepositoryID is guarded separately because it is the id an authorization check names the resource by), and a reader returning the resolution with the slug and repository name it was resolved for.
  • internal/format/maven/resolver.go: ResolveRepository replays a context-seeded resolution when its slug and repository name both match, and resolves in two tiers otherwise. Covered for the seeded hit (zero finder calls), slug mismatch, repository-name mismatch, and installed-but-unfilled holder, with NamespaceSuspended and a non-hosted kind pinned through the replay.
  • cmd/artifact-registry/wire_maven.go: buildMavenResolver and mavenDBProvider extracted so buildMavenDispatcher takes an injected resolver (nil-resolver panic guard added); part 2's authorization adapter shares that instance.
  • cmd/artifact-registry/wire_maven_route_pattern_test.go: pins that the mavenroute grammar and maven.RoutePattern describe the same mount, structurally and behaviorally.

Spec: S09 (authorization).

Stacked MRs (review/merge bottom-up)

Related to #652 (closed)

Edited by David Fernandez

Merge request reports

Loading
Loading