fix(deploy): pin the 0.1.7 soldeer tag's deploy constants

[thedavidmeister]

What this fixes

One of the two independent failures in rainix-sol / test on main:

[FAIL: a published soldeer tag is missing pinned deploy constants:
MISSING: DECIMAL_FLOAT_CONTRACT_HASH_0_1_7
LOG_TABLES_DATA_CONTRACT_HASH_0_1_7
ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS_0_1_7
ZOLTU_DEPLOYED_LOG_TABLES_ADDRESS_0_1_7 != OK]
testAllPublishedSoldeerTagsHaveAFullConstantSuite()

LibDecimalFloatDeploy carries a full suite for 0.1.1 and nothing for
0.1.7. The soldeer registry lists 0.1.7 as published, so the test that
obliges every published tag to carry its pinned suite fails. This adds the
four missing constants.

Why only 0.1.7

The registry lists exactly two published versions for rain-math-float,
0.1.1 and 0.1.7 — checked directly against the API with limit=100. The
sol-v0.1.2 … sol-v0.1.6 git tags exist but were never published, so they
are not in scope for this test and pinning them would assert nothing.

Where the values come from

A pinned suite is a derivation from that tag's own source, not an
observation of a chain: a Zoltu address is a function of bytecode + salt. So
pinning a published tag never waits on a broadcast.

constant	value
ZOLTU_DEPLOYED_LOG_TABLES_ADDRESS_0_1_7	0xc51a14251b0dcF0ae24A96b7153991378938f5F5
LOG_TABLES_DATA_CONTRACT_HASH_0_1_7	0x2573004a…420f
ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS_0_1_7	0x799632d282178e770C7465cad54aDA1021A913D6
DECIMAL_FLOAT_CONTRACT_HASH_0_1_7	0xdc468883…f55e

The log-tables address and codehash are identical to 0.1.1's because the
table bytecode did not change between the two releases.

QA

• Discriminating tests: testAllPublishedSoldeerTagsHaveAFullConstantSuite - fails on base (verified on main at d3fb611, and visible in rainix-sol / test on PR fix(test): drop vm.skip from the tagged deploy constants check #265 which does not carry this fix, with the MISSING: ..._0_1_7 list quoted above), passes with this change.
• Mutations applied: 2 applied, 0 killed, 2 SURVIVED - DECIMAL_FLOAT_CONTRACT_HASH_0_1_7 -> 0xdeadbeef...deadbeef -> SURVIVED, no killing test; ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS_0_1_7 -> address(0x...dEaD) -> SURVIVED, no killing test. Reported as found, not suppressed: the test asserts that the four names exist and never their values. See "Why the survivors are not fixed here" below.
• Oracle: the published sol-v0.1.7 tag's own source, read two ways independent of this branch's build - git show sol-v0.1.7:src/lib/deploy/LibDecimalFloatDeploy.sol, and a local rebuild at that tag whose keccak256(deployedBytecode) for DecimalFloat reproduces 0xdc468883...f55e. The two agree. Not read from an RPC, not copied from this repo's head.
• Category check: no issue - this is one of several independently diagnosed causes of red CI on main. Covers exactly one: the missing 0.1.7 suite in rainix-sol / test. The other failure in that same job, the five red testProdDeployment* tests, is a different cause and is deliberately not touched here.

Why the survivors are not fixed here

The obvious fix — assert the pinned value against
type(DecimalFloat).runtimeCode — would be wrong. It passes today only
because main's source still happens to equal 0.1.7, and the moment the
source legitimately changes it would force a rewrite of a frozen historical
pin to match new code. That is exactly backwards: the point of a per-tag
suite is that it records what that release was, permanently.

The durable fix is to assert that each pinned version is actually deployed at
its pinned address with its pinned codehash. That is blocked. The current
unsuffixed pin 0x799632…13D6 returns 0x from eth_getCode on arbitrum,
base and flare — it was never deployed — which is the same root cause as the
five red testProdDeployment* tests and needs an on-chain deployment, not a
test change.

Overlap with #256

⚠️#256 already contains this exact change, with byte-identical constant
values, as one commit inside a larger PR that also renames the codegen script
and rewrites CLAUDE.md. This PR is the same fix isolated. The two will
conflict — close whichever is less useful.

Scope

Constants only. No test is weakened, no assertion is removed, no deployment is
performed.

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in:44 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: ee02ebe9-ce8b-41bc-af01-f333be60338a

📥 Commits

Reviewing files that changed from the base of the PR and between d3fb611 and c02a3e5.

📒 Files selected for processing (1)

• src/lib/deploy/LibDecimalFloatDeploy.sol

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}