Both languages read the same words as a boolean flag

[bjmeetsfo]

There are two canonical boolean parsers, one per language:

crate::env_flag::parse_bool      "1"|"true"|"yes"|"on"  /  "0"|"false"|"no"|"off"
matrixark_mcp_env.env_bool       TRUE_VALUES            /  FALSE_VALUES

They agree — on the words, on trimming and lowercasing first, and on answering the caller's
default for a word neither knows. Nothing compared them.

Why the third of those matters most

tools/test_env_flag_vocabulary.py settled this for python and wrote down why: "Boolean flags
were parsed in six different vocabularies. They disagreed on the two words an operator is most
likely to reach for." Its scan reads os.environ.get shapes under tools/, so it could not see
the rust half of the same codebase — which kept the defect until #1308. Nine readers matched
"1" | "true" | "TRUE" | "yes" | "YES" with no trim and no lowercasing, and .map(...) ran
before .unwrap_or(default), so an unrecognised value came back false rather than the default.
Against a default-on flag:

"on" -> false   "On" -> false   "True" -> false   " 1" -> false   "wat" -> false

Every default-on flag in the tree reached one of them, so writing on to keep one on turned it
off, and so did a typo.

Both halves of that are pinned here: the word lists, and _ => None — the shape that makes an
unknown word fall back to the caller's default instead of to false.

What it checks

• The two TRUE sets match, and the two FALSE sets match. The rust side is read out of the source
  (it cannot be imported from tools/), by matching the => Some(true) / => Some(false) arms.
• Normalisation on both sides. Rust must still do raw.trim().to_ascii_lowercase(); the
  python side is driven, not read — env_bool is called with " on ", "ON", "\tTrue\n",
  " 1" and their false counterparts, which are the spellings a unit file, an export and a
  heredoc actually leave.
• An unreadable value falls back to the default, checked on both sides — _ => None in rust,
  and env_bool("wat", True) / env_bool("wat", False) driven in python, so a single assertion
  cannot pass by the function simply answering one way.

Scoped to the canonical parsers on purpose. raft.rs also accepts y/n and control.rs also
accepts enabled; both are intentional supersets that normalise correctly, and this does not
touch them.

It discriminates

Checked by perturbing the rust side three ways and watching it fail, then restoring:

perturbation	result
"on" dropped from the TRUE arm	FAILED
.trim().to_ascii_lowercase() dropped	FAILED
_ => None changed to _ => Some(false)	FAILED
restored	OK

The readability of the arms is asserted first, since both set comparisons would otherwise pass on
an empty scan.

No production code changes.

🤖 Generated with Claude Code