wallet/domain: replace bch_loops proxy for 'Leibniz active' with the bch_leibniz mask

[fpelliccioni]

Context

src/domain/include/kth/domain/chain/token_data.hpp::max_token_commitment_length(script_flags_t flags) — and legacy call-sites like src/blockchain/src/validate/validate_input.cpp:105 — use `machine::script_flags::bch_loops` as a proxy for "the 2026-May Leibniz upgrade is active". BCHN, for comparison, uses the dedicated `SCRIPT_ENABLE_MAY2026` bit for the same gating (see `src/consensus/src/bch-rules/script/script_flags.h:128`).

Using `bch_loops` (which semantically only flags the new `OP_BEGIN` / `OP_UNTIL` opcodes) to decide the commitment-size cap, pay-to-script pattern changes, etc. is confusing:

• The flag name has nothing to do with what is being gated.
• The check fails if a network configuration enables some Leibniz features but not `bch_loops` — even though commitment size is a consensus-wide change, not an opcode-specific one.
• Readers have to cross-reference the comment on the flag definition to understand what the check is actually guarding.

Proposal (Option B from PR #288 discussion)

Replace the per-feature `bch_loops` proxy with the existing aggregate mask `machine::bch_leibniz` (= `bch_galois | bch_loops | bch_subroutines | bch_bitwise_ops | bch_p2s`) at every call-site that uses `bch_loops` as a stand-in for the full upgrade:

```cpp
// before
script_basis::is_enabled(flags, machine::script_flags::bch_loops)

// after
script_basis::is_enabled(flags, machine::bch_leibniz)
```

`is_enabled` is an ANY-bit check, so this matches BCHN's single-bit `SCRIPT_ENABLE_MAY2026` semantics whenever the network activator sets the Leibniz bits together (which is the normal case).

Scope

Known call-sites to update (as of commit `af2d1d8`):

• `src/domain/include/kth/domain/chain/token_data.hpp` — `max_token_commitment_length`
• `src/blockchain/src/validate/validate_input.cpp:105`

Grep for `bch_loops` outside `script_flags.hpp` before submitting, since other files may have adopted the same proxy.

Non-goals

• Do NOT retire `bch_loops` — it remains the correct flag for opcode-level checks (the `OP_BEGIN`/`OP_UNTIL` interpreter path).
• Do NOT introduce a brand-new `bch_may_2026` bit; the existing `bch_leibniz` aggregate is the closest equivalent to BCHN's pattern and is already defined in `script_flags.hpp`.

Acceptance

• All non-opcode `bch_loops` call-sites switched to `bch_leibniz`.
• No test regressions.
• Comments at each call-site explain that the check is for "any Leibniz-era flag set" and reference the BCHN equivalent.

References

• PR feat(wallet): add cashtoken_minting API #288 "feat(wallet): add cashtoken_minting API" — discussion that surfaced the legacy naming.
• BCHN: `src/consensus/tokens.cpp:72-80` — uses `SCRIPT_ENABLE_MAY2026` for the same cap decision.
• Knuth mirror: `src/consensus/src/bch-rules/script/script_flags.h:128`.