doc: correct the catalog_server_explain claim for a new builtin log

The design doc says `catalog_server_explain.slt` needs no change when a builtin
log is added, on the grounds that its query filters `o.id NOT LIKE 'si%'` and so
never enumerates a per-replica introspection index. The filter is real, but the
conclusion does not follow. The plans already in the file embed the inlined
builtin `VALUES` sets as `Constant (N rows)` nodes, so every count over a catalog
relation that gained a row moves, and adding an ontology entity and link moves two
more.

Record the question that catches this: not whether a new plan appears, but whether
the existing plans change.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018ZVCMBSLdxzGus78ZKWhZz

Author: claude

doc/developer/design/20260817_compute_hydration_timestamps.md

@@ -683,9 +683,15 @@ Goldens that hardcode a log relation's identity, columns, OIDs or indexes:
 `test/workload-replay/system_catalog_identifiers.txt` and `objects.txt`. Docs: the
 `mz_introspection` system catalog reference page.
 
-`catalog_server_explain.slt` and `test/cluster/mzcompose.py` need no change. The
-former's query filters `o.id NOT LIKE 'si%'`, which excludes per-replica
-introspection log indexes, and the latter queries named relations.
+`catalog_server_explain.slt` needs its `Constant (N rows)` counts bumped. Its query
+filters `o.id NOT LIKE 'si%'`, so no new EXPLAIN entry appears for the per-replica
+log index, but the existing plans embed the inlined builtin `VALUES` sets as
+constant nodes, so every count over a catalog relation that gained a row moves,
+including the two ontology counts moved by the new entity and link. The question a
+new builtin raises here is not whether a plan is added but whether the existing
+plans change.
+
+`test/cluster/mzcompose.py` needs no change, since it queries named relations.
 
 Not touched, and deliberately so: the introspection subscribe,
 `mz_internal.mz_compute_hydration_times`,