policy: count bare data envelopes (OP_2DROP/pushnum runs) as datacarrier

[kwsantiago]

DatacarrierBytes recognizes inscription data in two forms: OP_FALSE OP_IF ... OP_ENDIF envelopes and <data> OP_DROP. It does not match OP_2DROP, so a bare envelope of the form push <marker> <data>... OP_2DROP...OP_DROP counts as zero datacarrier bytes and evades the size limit.

This is the envelope shape ordinals/ord#4545 adopts to remain valid under BIP-110, which disables OP_IF/OP_NOTIF in tapscript.

Changes:

• Count a contiguous run of pushes/pushnums that is balanced by OP_DROP/OP_2DROP, anchoring data_began at the start of the run so the whole run is counted on the first drop rather than just the last push.
• Treat pushnums (OP_1NEGATE, OP_1..OP_16) as run members. ord's parser accepts pushnums as payload, so a pushnum interleaved between data pushes must not strand the earlier push from the count. This matches the counting to exactly the grammar ord's envelope parser accepts (pushes, pushnums, OP_DROP, OP_2DROP).

This makes counting slightly stricter for any push-run ending in a drop, not only the new envelope. Standard scripts that use OP_DROP drop a stack item preceded by a non-push opcode (e.g. <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP), which breaks the run and is not counted.

Testing:

• Unit (script_DataCarrierBytes): a <data> <data> OP_2DROP run, and a pushnum-interleaved <data> OP_7 <data> OP_2DROP run.
• Functional (mempool_datacarrier.py): builds P2TR script-path spends with bare envelope tapscripts and asserts txn-datacarrier-exceeded under default policy, including a pushnum-interleaved envelope, mirroring the existing OPNet case. Reverting the counting change alone makes the tests fail (the tx is accepted).

[Retropex]

tACK 3b776a4

Tested with this transaction (has been mined afterward to be able to share it publicly) on my own signet.

[pdath]

I ran the code changes through a CodeRabbit review, and no issues came up.