Bump rain-math-binary 0.1.3 -> 0.1.4

[thedavidmeister]

This repo pins rain-math-binary = "0.1.3". The latest published release is 0.1.4.

The change: foundry.toml, remappings.txt, soldeer.lock, and the rain-math-binary-0.1.3/ import prefix in src/lib/parse/LibParseMeta.sol, src/lib/codegen/LibGenParseMeta.sol, test/src/lib/codegen/LibGenParseMeta.findExpander.t.sol, test/src/lib/codegen/LibGenParseMetaSlow.sol. Confirm that file list against the checkout rather than trusting it.

What the bump buys, and what it does not

rain.math.binary/src/ has changed once since 2024 — 90244afc (2026-07-18), NatSpec on ctpop/ctpopSlow and a comment correction. There is no behaviour change between 0.1.3 and 0.1.4. This is not a fix.

The reason to do it is that the org carries two pins of a one-library package: rainlang on 0.1.1, rainlang.interface and rain.extrospection on 0.1.3. Converging on 0.1.4 removes the split, so the next bump — one that does change behaviour — is a single coordinated move rather than a reconciliation.

Why this cannot be judged repo-locally

Soldeer is flat, and foundry resolves a dependency's imports using the CONSUMER's remappings. Every repo pulling this one must therefore declare rain-math-binary at exactly the version this repo's import paths name. That is why raindex, rain.erc4626.words, rain.flare, rain.merkle and rain.pyth all pin 0.1.1 while referencing LibCtPop nowhere themselves.

Merging this does not break them — they keep building against the release of this repo they already pin — but each needs its own pin moved to 0.1.4 when it next takes a release of this repo. That coordination is the cost, and it belongs in the PR body.

[thedavidmeister]

This one is the unblocker for the chain, and the missing step is a publish rather than a code change.

main here already imports rain-math-binary-0.1.3 (src/lib/parse/LibParseMeta.sol:5, src/lib/codegen/LibGenParseMeta.sol), but the latest published rain-interpreter-interface is 0.1.2, and that artifact still pins rain-math-binary 0.1.1. rainlang pins rain-interpreter-interface = 0.1.0, whose compiled src/ therefore imports rain-math-binary-0.1.1/ — on rainlang's compile path via src/lib/parse/LibParse.sol and script/Build.sol. So no combination of currently published versions lets rainlang move off 0.1.1, which is why rainlanguage/rainlang#551 is red and blocked.

Order to unblock: bump here to 0.1.4, merge, publish a rain-interpreter-interface release carrying it, then rainlang#551 retargets to 0.1.4 and moves its rain-interpreter-interface pin to that release in the same commit.