feat(datastore): add the maven_virtual_upstream_rules schema (S30 plan: 3/25)

Adds the per-association rule table for Maven virtual repositories: parent plus 64 HASH(namespace_id) partitions, CHECKs bounding rule_type to two values, target_field to three, and pattern to 255 characters, the (namespace_id, maven_virtual_repository_upstream_id) index, and the ON DELETE CASCADE key from the upstream association as a trailing ALTER TABLE ... ADD CONSTRAINT. Same shape as the upstreams table in !2719 (merged): the Up runs unbounded per issue 548, only the Down sets lock_timeout and statement_timeout inside a RESET bracket.

Tests are one integration file, same scope as !2719 (merged). The plan's Step 3 entry is amended in !2765 (merged) to record that scope, as !2727 (merged) did for Step 2. Three behavioral tests: every enumerated rule_type and target_field value is accepted, with a 255-character multibyte pattern at the cap; the rows the table refuses (each discriminator one below and one above its range, a 256-character pattern, an absent association, a cross-namespace pair); and the two cascades, an association delete removing its rules and a parent repositories delete removing the virtual row, its upstreams, and their rules. Three static checks pin what the dump cannot see: the migration shape (NO TRANSACTION, the trailing key, one DROP per statement), the Up replaying cleanly over an existing table, and the Down timeout bracket. Columns, index names, and key actions are left to structure.sql.

No e2e catalog change and no docs/user change: the table is reachable only by direct SQL until the management API and the virtual resolver land.

Hand-written diff is 695 lines in one MR: 369 are the migration, and the 64 partition creates plus their 64 drops are most of that. The test file is 326 lines; two existing test files change one line each. structure.sql and internal/datastore/jet/** are generated. Splitting the partition list off the table it partitions would leave two halves that only make sense together.

Database Review Evidence

Migrations

Note

Timings are from CI (db:migrate matrix, goose verbose) against an empty database, in apply / rollback order per PG version. Production-scale validation via Database Lab is not yet available. See Database review evidence for the matrix rationale and how to read the numbers.

Migration	PG 16	PG 17	PG 18
20260917090000_create_maven_virtual_upstream_rules.sql	OK (1.17s / 368.12ms)	OK (459.72ms / 241.71ms)	OK (834.29ms / 350.32ms)

Migration notes:

• create_maven_virtual_upstream_rules.sql: apply is over 1s on PG 16. The time is 64 partition creates plus one index and two foreign keys on empty tables, catalog writes with no row scan, so production runtime matches CI and sits far inside the 5-minute boot budget. Same shape and range as the two sibling tables (!2697 (merged): 0.5s to 1.06s, !2719 (merged): 0.53s to 1.72s).

Related to #289 (closed)