Keep OP_0 OP_IF data envelopes byte for byte

[codenlighten]

Problem

An OP_0 OP_IF … OP_ENDIF block never runs, so rewriting what is inside it does not change what the script does, and the symbolic proof and differential tests pass. But that is where inscription envelopes (1Sat Ordinals, BSV-21 and similar) carry their data, and the optimizer was rewriting it:

before: OP_0 OP_IF 6f7264 OP_1 746578742f706c61696e OP_0 <60B> OP_0 <60B> OP_ENDIF OP_DUP OP_HASH160 … OP_CHECKSIG
after:  0    OP_IF 6f7264 OP_1 746578742f706c61696e 0    <60B> 0    OP_OVER OP_ENDIF OP_DUP OP_HASH160 … OP_CHECKSIG

The second field became OP_OVER, so an indexer no longer sees the inscription. A body like OP_1 OP_1 OP_ADD OP_DROP was also removed from inside an envelope entirely.

Fix

• parse turns an OP_0 OP_IF … OP_ENDIF block into one verbatim op (DEAD), the same way the tail after a top-level OP_RETURN is kept. It only does this when the block has no OP_ELSE of its own (that branch would run) and has a matching OP_ENDIF with no truncated pushes, and contains no OP_VERIF/OP_VERNOTIF. A nested IF/ELSE inside the block is fine.
• Those two opcodes are excluded because, in a branch that does not run, they open a conditional after Chronicle but do nothing between Genesis and Chronicle, so the end of the block depends on the era. Counting them as openers let 1 IF 0 IF VERIF ELSE DROP ENDIF ENDIF be taken as one dead block, although its DROP runs before Chronicle: OP_DUP OP_DROP after it was removed, and a script that failed on a one-item stack came out succeeding, with the symbolic proof passing (ed56b3d).
• In analysis, the block is a barrier with stack effect [g, ga]: it pushes OP_0 and pops it. Code after the envelope keeps the stack guarantee it had before, so the optimizer still removes redundant ops there. OP_1 OP_DUP OP_DROP <envelope> OP_DUP OP_DROP still minimizes to OP_1 <envelope>.
• toAsm prints the block's real ASM, so --asm output round-trips. profile reports it as data (OP_0 OP_IF block), and push re-encoding skips it.
• The README section on barriers now mentions these blocks.

Tests

• New unit test: the envelope comes out byte for byte, the code around it is still optimized, the block parses, encodes and prints as expected, and the OP_ELSE, nested ELSE and unterminated cases are handled.
• New fuzz test (wide opcode fuzz with stacks that pass checks), 150 scripts. It covers every modelled opcode including CHECKSIG, CODESEPARATOR, Chronicle opcodes and shifts (with small size operands); non-minimal pushes, negative zero and 4/5-byte number boundaries; OP_NOTIF; OP_RETURN and OP_0 OP_IF blocks inside branches; and PICK/ROLL with a computed index. Starting stacks are biased toward passing checks.
• Unit test for the OP_VERIF case: it fails without ed56b3d.
• npm test: 25/25 pass.
• A fuzz of OP_0 OP_IF blocks containing OP_VERIF/OP_VERNOTIF inside other conditionals, checked on the interpreter under both Chronicle and Genesis-only flags: 2 mismatches in 6,000 checks before ed56b3d, 0 after.
• Separately, a longer run of a similar generator (without the OP_0 OP_IF blocks) found no mismatches: 1,600 scripts on main and 200 on this branch, about 430k interpreter runs in total under consensus and policy flags (MINIMALDATA, MINIMALIF, NULLFAIL), about 78k of them successful.

Not in this PR

• toAsm still prints the tail after a top-level OP_RETURN as <tail N bytes>, so --asm -o output loses that data. Hex and binary output are fine.
• The Node 24 job took 7m21s on ed56b3d because the wide fuzz test generated a script with a constant ROLL index of 88,547, which made the scheduler quadratic. That is fixed in Abandon schedules far larger than the fragment they would replace #2 and applies to main as well.