feat: bring multichain launch entry points to Base parity

[0xCaps]

The missing piece

ReadWriteFlaunchZapMultichain implements 2 methods. The base zap client implements 11. Everything else on FlaunchSDK routes unconditionally to readWriteFlaunchZap, which is never constructed for a multichain deployment — so on Robinhood you get an internal-sounding error instead of a launch:

Base             flaunchWithRevenueManager -> proceeds to network
Robinhood (4663) flaunchWithRevenueManager -> readWriteFlaunchZap is not supported on chain 4663

Separately, multichain flaunch() threw outright on any treasuryManagerParams.

The contract has supported this the whole time. FlaunchZap exposes flaunch/2 and flaunch/3, and flaunchWithDynamicSplitManager already writes the three-argument form. Only the client surface was missing.

What this changes

Added to the multichain client, encoding copied from the base client rather than reinvented:

Entry point	Before on 4663	After
flaunch (with manager)	threw	✅ flaunch/3
flaunchWithRevenueManager	threw	✅
flaunchIPFSWithRevenueManager	threw	✅
flaunchWithSplitManager	threw	✅
flaunchIPFSWithSplitManager	threw	✅
flaunchIPFS	threw	✅
flaunchIPFSWithDynamicSplitManager	threw	✅

All seven now dispatch on isMultichainDeployment, matching how flaunch and flaunchWithDynamicSplitManager already worked. The entry point is parity regardless of which position-manager version sits underneath — callers stop needing per-chain capability tables.

Why the overload selection is load-bearing

flaunch() picks the overload by manager presence. Getting this wrong does not throw: the two-argument overload produces a valid transaction that silently drops the manager and routes fees to the default treasury. The tests therefore assert argument count and manager params directly rather than just "it didn't revert".

Verification

• 33 tests pass (was 24). New coverage: revenue-manager deposit encoding, static-split deployment, and that plain launches still use flaunch/2, across all three multichain deployments.
• Verified read-only against the live Robinhood zap. Using two real manager instances found in ManagerDeployed logs on the factory, eth_call succeeds and returns the existing instance as deployedManager_ — confirming the zap deposits into it rather than redeploying:

Instance	deployedManager_
0xBa824C9a…	0xBa824C9a… ✅
0xfed0044A…	0xfed0044A… ✅

• Built artifact confirmed: Robinhood and Base now behave identically at the entry point.

Two tests changed

factoryAndGuards asserted flaunchIPFSWithDynamicSplitManager is base-only, and multichainLaunch asserted treasury managers reject. Both encoded the limitation being lifted.

Notes for review

• Pre-existing quirk preserved. The static-split remainder is total - recipients - owner, without subtracting the creator split, so a 20% creator split with 80% recipients yields 40%. Copied verbatim from the base client for parity; flagging it since it looks unintentional and may deserve a separate fix on both paths.
• Out of scope: deployRevenueManager / deployStakingManager / deployBuyBackManager. Those need readWriteTreasuryManagerFactory, which is also unconstructed on multichain. The factory is deployed at 4663 with all three implementations approved, so it is a viable follow-up — kept out to keep this diff to launch entry points.
• Unrelated packaging bug spotted: ./addresses and ./utils declare CJS entry points (dist/addresses.cjs, dist/utils/index.cjs) that don't exist in the published tarball, so require throws while types resolve. Consumers have to import everything from the package root.

Downstream

flaunch-web2-api currently calls the zap directly to work around this (#60). Once this ships, that bypass gets deleted in favour of flaunchWithRevenueManager. peripheral-gtm hardcodes chainSupportsRevenueManager() === "base" and can drop that too.

🤖 Generated with Claude Code