feat(compat): both Percona distributions are full relatives, measured rather than assumed (#424)

[cevheri]

Continues #424 Phase 0. Stacked on #506, which is itself stacked on #503 — review in that
order and each diff reduces to its own commit.

The two cheapest names left on Phase 0's list. The reason to spend a probe on a drop-in build
at all is that "drop-in" is a claim someone else makes, and this list's rule is that a name
counts after we connect to it.

Engine	Verdict	Probed
Percona Server for MySQL 8.4.11-11	full via mysql	percona/percona-server:8.4
Percona Distribution for PostgreSQL 18.6.1	full via postgres	percona/percona-distribution-postgresql:18.6

What was measured

Both called surface by surface through the real provider, then read again in real Chrome against
bun run build && bun run start.

Percona Server for MySQL — all fifteen surfaces answer. Row counts and sizes are correct
(2000 rows read as 2000, 114688 bytes as 114688, index 65536), indexes and a foreign key are read
back, EXPLAIN FORMAT=JSON parses, and all three maintenance actions succeed: Analyze,
Optimize (InnoDB's own Table does not support optimize, doing recreate + analyze instead; OK)
and Check. Browser pass: tree probe_customers 3 / probe_orders 2.0k, zero failed API
requests, Monitoring rendering version, uptime, Connections 9/151, DB Size 192 KB,
Cache Hit 97.5%, Tables 2 / 2 indexes.

Percona Distribution for PostgreSQL — same result on the other side: all fifteen answer, 2000
rows and 131072 bytes read exactly, foreign key and indexes read back, Analyze and Vacuum both
work, zero failed API requests in the browser.

The one asymmetry, and why it gets a test

The pair differs in exactly one thing, and it is the trap Garnet's row records — landing on only
one of them:

• Percona for PostgreSQL names itself in version() — PostgreSQL 18.6 - Percona Server for
  PostgreSQL 18.6.1 — so the product displays it and there is nothing to mistake for stock;
• Percona Server for MySQL answers a bare 8.4.11-11 and keeps its identity in
  @@version_comment (Percona Server (GPL), Release 11, Revision 57878ff8), which the provider
  does not read. Browser-verified: Monitoring reads MySQL 8.4.11-11.

A unit test pins that asymmetry in both directions — the MySQL row must carry the
@@version_comment caveat and the PostgreSQL row must not — because a copied caveat is how a
pair of rows stops describing two different measurements.

D32: found here, belongs to the baseline

While writing the MySQL caveats, getHealth() was seen returning
slowQueries: [{ query: "Performance schema not available", … }] on a server whose
@@performance_schema is 1 and whose slow-query panel returns rows.

Measured identically on a stock MySQL 26.7.0 in the same pass, which is what settles the
attribution: it is ours and pre-existing, not Percona's and not caused by this work. It is a
fabricated absence rather than a missing number — the class the absence rule (#477) exists to
prevent — and the panel beside it disproves the statement. Filed as D32, not fixed: the honest
fix is either the rows getSlowQueries() already produces or no line at all, and that is a change
to the MySQL health read with its own coverage.

It took a drop-in build to notice, because a caveat had to be written about a reading that turned
out to be the baseline's.

Counts

Relatives 21 → 23, published figure 35 → 37, both re-derived from connectableProductCount()
(14 external drivers + 23 relatives). No new driver, no new dependency. Both compose services are
pinned — for the MySQL one the tag is the only durable record of which build was measured, since
version() does not name it.

Verification

format · lint · typecheck · knip · build · tests/run-core.sh (351 files) ·
tests/run-components.sh (33 groups). Browser pass on the built app: hero reads Plus 23
wire-compatible engines and names both rows; the MySQL hint names Percona Server for MySQL and the
PostgreSQL hint names Percona Distribution for PostgreSQL, both with no tier suffix, which is
how a full relative renders.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud