26 pre-existing failures in test-commands.sh, now visible after the #679 abort fixes

[TinDang97]

26 failing rows in scripts/test-commands.sh, visible for the first time

#679 fixed the aborts that stopped this suite from ever reaching its summary.
With the run completing, the totals are:

  Total:  504
  Passed: 478
  Failed: 26
  STATUS: FAIL (26 failures)

These 26 are pre-existing — they are not regressions from the harness fix.
Several appear verbatim in logs from before it (ROLE, the four
FT.SEARCH/FT.RECOMMEND substring rows, FT.INFO after drop). They were
invisible because the script died before printing totals, and in some cases
before reaching the row at all.

Note also that CLAUDE.md described this suite as "190 tests"; the real figure
is 504 rows. That has been corrected.

The failures

• TTL after EXPIREAT
• COMMAND (got error)
• ROLE
• FT.SEARCH returned error
• FT.INFO after drop errors
• FT.SEARCH KNN (expected substring 'doc:')
• FT.SEARCH LIMIT (expected substring 'doc:')
• FT.RECOMMEND basic (expected substring 'doc:')
• FT.SEARCH tag filter (expected substring 'doc:')
• FT.SEARCH multi-term AND returned no results
• FT.SEARCH stop-words-only should return ERR (got: 0)
• FT.SEARCH cross-field should find 'world' in doc:t1
• MIXED %%machne%% deep returned no docs: 0
• TAG-05 expected explicit rejection, got: 8
• NUMERIC-05 expected 'min > max' rejection, got: numeric_filter_invalid
• HYB-01 two-way hybrid errored: ERR query vector dimension mismatch
• HYB-01 response missing __rrf_score: ERR query vector dimension mismatch
• HYB-03 WEIGHTS errored: ERR query vector dimension mismatch
• HYB-02 missing sparse field should error: ERR query vector dimension mismatch
• TXN COMMIT should return OK: ERR not in a cross-store transaction
• GET after TXN ABORT (insert) should be nil: should_vanish
• GET after DEL + TXN ABORT should return original:
• Double TXN BEGIN should error: OK
• MQ PUBLISH inside TXN should return QUEUED: ERR MQ PUBLISH requires an active transaction (use TXN BEGIN first)
• MQ POP after TXN COMMIT should contain message:
• GET after KV+MQ TXN ABORT should be nil: should_vanish

Rough grouping

• Cross-store TXN (6) — TXN COMMIT should return OK: ERR not in a cross-store transaction, Double TXN BEGIN should error: OK, and the
  abort-semantics rows (should_vanish). Either the rows encode a design that
  changed, or TXN BEGIN/COMMIT is genuinely not behaving as written.
• Vector / FT.SEARCH (10) — mostly ERR query vector dimension mismatch
  and empty result sets on testidx. The fixture and the index schema appear
  to disagree about dimensionality.
• Text search (4) — multi-term AND, cross-field, stop-words-only,
  and a fuzzy %%machne%% row returning no documents.
• Error-string drift (2) — NUMERIC-05 expects min > max but gets
  numeric_filter_invalid; TAG-05 expects an explicit rejection and gets a
  count.
• Known separately (1) — ROLE is ROLE/INFO: master_repl_offset advances with no replica ever attached (Redis holds it at 0) #536.
• Remaining (3) — TTL after EXPIREAT, COMMAND (got error), and the MQ
  in-transaction rows.

Each group needs the same judgement call: is the row asserting behaviour moon
should have (a real bug), or behaviour moon deliberately does not have (a stale
expectation that should be rewritten to assert what moon actually does, the way
#679 handled the VECTOR FLAT row)? Neither answer should be reached by
weakening the assertion until it passes.

How this surfaced

Fixing #679. Filed separately rather than folded in, because #679 is about
making the suite run and report — deciding the fate of 26 assertions is its own
piece of work.

[TinDang97]

Status: 26 → 1, and the one that remains is tracked separately.

wave	failures	what closed them
filed	26	—
#694	4	8 harness defects (TXN probes desyncing a shared connection, $( ) eating NUL bytes from vector fixtures, a rounding-sensitive TTL row, non-discriminating greps)
#696	1	#690 (2 rows), #693 (1 row), #691 (made NUMERIC-05 discriminating)

The survivor is FT.SEARCH "*" on a VECTOR-only index — the open half of #693, now tracked
as #695. It asserts the RediSearch behaviour rather than moon's error, so it goes green on its
own when that lands. ROLE (#536) was resolved separately.

A defect in the suite itself, found while verifying the above

Both server-startup guards were structurally unreachable. rcli() and mcli() end in
|| true, which is right for the ~500 assertion rows but fatal for the health checks built on
them:

mcli PING >/dev/null 2>&1 || { echo "moon failed to start"; exit 1; }   # can never fire

Measured against the pre-fix script with a binary that never listens:

old:  86 rows ran, 10 of them PASSED
new:  0 rows, exit 1, "moon failed to start (no PONG on its port after 10s)"

Those 10 are the vacuous-assertion class — FT.SEARCH does not error and FT.SEARCH stop-words-only returns no documents are both satisfied by an empty reply, because empty
contains neither "err" nor "doc:". This is not hypothetical: it produced a 41-failure run
during this work that was briefly taken at face value before being repeated clean.

Fixed in #696. The probes now match the actual PONG rather than an exit status (so a foreign
process holding the port cannot fake liveness either — moon uses SO_REUSEPORT, which makes that
real), and they poll instead of sleep 1, because a cold first exec of a freshly built 21MB
binary can take longer than a second — the other half of the same bug. RUST_BINARY is now
${MOON_BIN:-./target/release/moon}, which makes the guard reproducibly testable
(MOON_BIN=/usr/bin/false) and lets the suite be aimed at a known build.

I would suggest keeping this issue open until #696 merges, then closing it against #695 as the
sole remaining row.