Regenerate the flag inventory, and say why the index-log compression flag has two paths

[bjmeetsfo]

TS_INDEX_LOG_COMPRESSION_ENABLED and TS_INDEX_LOG_COMPRESSION_MIN_BYTES landed in index_log.rs without the generated inventory being regenerated. Two guards are red on main because of it, and on every branch cut from main:

• test_every_flag_named_in_the_engine_is_listed — the engine names flags the document does not list.
• test_regenerating_produces_the_same_document — the counts on paper no longer match the tree.

Regenerating adds both rows. That surfaces the boolean to test_a_two_path_flag_says_why, which wants a recorded reason for its off side, so the second half of this supplies one taken from what the engine already says at the read:

Whether new index-log payloads are written compressed. Off by default. Reading codec 2 is unconditional; only writing it is gated, so a store can be rolled forward and back without a migration.

I derived that from the code rather than from the author, so if the intent was different the wording is the part to correct.

This is the third time

Same two guard names, third occurrence — #1269 and #1321 were the same thing with different flags. The detector works; it just reports on the next pull request rather than on the one that added the flag, so the cost lands on whoever pushes next and the staleness accumulates until someone regenerates.

Worth a maintainer decision rather than another regeneration from me: either the ratchet blocks merge, or the inventory stops being a committed artifact that can drift. I have not changed either here.

Checked: test_a_two_path_flag_says_why, test_matrixark_engine_flag_inventory, test_matrixark_engine_settings_match_the_engine, test_matrixark_every_live_claim_is_checked and test_the_loader_maps_every_config_key all pass. No engine code changes.

🤖 Generated with Claude Code