refactor(maven): relocate protocol SQL into per-entity datastore stores

📖 What this MR does

Relocates all Maven protocol SQL from internal/format/maven/store.go (deleted, 1367 lines) into four per-entity stores in internal/datastore/ on the generated Jet models, converging Maven on the layout npm and container already use:

• MavenRepositoryStore — repository-by-name resolution (new MavenRepositoryResolution projection), FOR SHARE re-verify, and the three S18 repository-counter no-op stubs carried forward unchanged.
• MavenPackageStore — two-trip find-or-create, FOR UPDATE re-verify, and the BumpAccessTimestamps no-op stub.
• MavenVersionStore — find-or-create, live-version count/exists, keyset ListLiveVersions.
• MavenFileStore — the three file lookups (package-level metadata lookup returns the new MavenMetadataFileResolution projection), both upserts, and the full conflict-target helper cluster.

Every store method takes an explicit db qrm.DB; wire_maven.go composes the stores behind the existing maven.Store seam through an adapter carrying a db func() qrm.DB provider closure (the wire_oci.go idiom). This resolves the Maven half of the store construction-shape divergence tracked in #256 (the npm half stays open there).

On the format side, the four consumer interfaces survive retyped to the Jet models; the format-local row structs, their model converters, the dead FindRepository interface method (only the resolver seam ever called it, through the wire adapter), and the maven.Kind type (replaced by the datastore.RepositoryKind* constants already used everywhere else) are deleted. The upload path's RunInTx transaction composition is untouched; the reconciler's pre-transaction pool read is now explicit (r.tx.DB()) instead of the removed nil-means-pool convention.

🎯 Why a single MR instead of a stack

A two-MR split (additive stores, then cutover) was considered and rejected: the datastore additions, the format-package cutover, and the wiring rewrite are compile-coupled, so any split either leaves an intermediate state with two live copies of every query on main or an MR that cannot compile independently. Shipping the relocation atomically keeps exactly one home for Maven SQL at every point in history.

✅ Behavior preservation

• SQL moved verbatim: identical tables, columns, join order, predicates, conflict targets, partial-index predicates, DO UPDATE SET lists, lock clauses, limits, and orderings.

• All 75 subtests of the original store_integration_test.go suite are preserved: 70 relocated verbatim into per-entity internal/datastore integration suites, 1 renamed (the maven.Kind assertion became a datastore.RepositoryKindHosted assertion), and 4 argument-guard subtests promoted to fast recordingDB unit tests (new coverage in the unit lane — guards previously ran integration-only).

• Digest fields cross the Jet []byte/*[]byte boundary through length-validated helpers mirroring npm's sha256SumFromBytes, with a round-trip unit test.

• Verified locally: full unit suite, internal/datastore + internal/format/maven integration suites against real PostgreSQL, race detector on the changed packages, go vet (both lanes), golangci-lint clean vs merge base.

• The Maven conformance suite (conformance:maven:s3-garage) gates this MR in CI as the end-to-end behavior oracle.

• One deliberate exception, from review hardening (08e53394): three digest-read paths that previously proceeded on a wrong-length stored digest column now fail closed with 500 — sidecar GET synthesis, the sidecar PUT sha512 comparison, and primary GET/HEAD sha1 validation. Unreachable while the columns' NOT NULL length CHECK constraints hold, but wire-visible on record.

🧪 E2e scenario impact

None — behavior-preserving relocation whose only wire-visible delta is the unreachable fail-closed exception noted above, so no catalog scenario in docs/testing/ is added or affected.

Related to #372 (closed)