fix: KEEP-456 route superfluid grant-flow-operator through CFAv1Forwarder

[suisuss]

Summary

Routes the superfluid/grant-flow-operator action via the canonical CFAv1Forwarder instead of the SuperToken's convenience proxy. The proxy is missing entirely on Sepolia's stubbed fUSDCx test token (even view methods revert), and silently relies on every real-deployment SuperToken implementing the thin delegate. The forwarder is the canonical entry point and works for any registered SuperToken.

Also strengthens the on-chain test from "tolerate any non-ABI revert" to assert positive simulation success -- the loose assertion masked the routing bug for months.

Closes KEEP-456.

Why this matters

The bug surfaced while smoke-testing the KEEP-438 kh CLI patch end-to-end against prod. Of the four superfluid workflow fixtures, three ran to completion on Sepolia (get-net-flow, create-pool, wrap) but grant-flow-operator reverted at the contract layer with no revert reason -- masquerading as the "quirky" behavior implied by the fixture filename.

Reproduction (Sepolia mainnet RPC, sender 0xB367...):

Target	Args	Result
SuperToken 0xb598...d443B (current routing)	updateFlowOperatorPermissions(0x...0001, 1, 0)	revert (no data)
SuperToken 0xb598...d443B	any permissions in {1,3,7} and flowRateAllowance in {0, 1000000}	revert (no data)
SuperToken 0xb598...d443B	even view function CONSTANT_OUTFLOW_NFT()	revert (no data)
CFAv1Forwarder 0xcfA132E353cB4E398080B9700609bb008eceB125	updateFlowOperatorPermissions(token, 0x...0001, 1, 0)	returns true

This Sepolia fUSDCx implementation is stripped/stubbed and doesn't expose CFA agreement methods. The bug is invisible on mainnets where SuperTokens have full implementations -- but routing through the forwarder is the right design regardless: it's what Superfluid's docs recommend, it works on every registered SuperToken (no per-implementation dependency), and it matches the sibling create-flow / update-flow / delete-flow actions which already route through cfaForwarder.

What changed

File	Change
protocols/superfluid.ts	Added 4-arg updateFlowOperatorPermissions(token, flowOperator, perms, flowRateAllowance) to CFA_FORWARDER_ABI; removed unused 3-arg from SUPER_TOKEN_ABI; rerouted action to cfaForwarder with token as first input
tests/integration/fixtures/superfluid-workflows/grant-flow-operator.json	Renamed from -quirky.json (the routing was the quirk); contractAddress -> token; _protocolMeta.contractKey -> cfaForwarder
tests/integration/protocol-superfluid-onchain.test.ts	Replaced loose expect(msg).not.toMatch(ENCODING_ERROR_RE) with strict expect(msg).toBe("") (forwards must simulate cleanly). Pinned routing in test name and inline comment so the bug can't regress silently.
tests/unit/superfluid-protocol.test.ts	Updated CFA forwarder ABI count (5 -> 6), SuperToken ABI count (5 -> 4), SuperToken action slug count (5 -> 4); moved grant-flow-operator into its own describe block with new contract === "cfaForwarder" and 4-input-order assertions

No address-map changes -- forwarders use sameOnAllChains() and Superfluid pins identical addresses across every chain in SUPERFLUID_CHAIN_IDS.

Test plan

• pnpm test tests/unit/superfluid-protocol.test.ts -- 41/41 pass
• pnpm test tests/integration/protocol-superfluid-workflow-fixtures.test.ts -- 21/21 pass
• INTEGRATION_TEST_RPC_URL=... pnpm test tests/integration/protocol-superfluid-onchain.test.ts -- 17/17 pass; the grant-flow-operator test now asserts positive simulation success
• pnpm exec biome check clean on touched files
• pnpm type-check -- no errors introduced (pre-existing @/lib/credential-map / @/lib/step-registry errors unrelated to this change, verified by stash + re-run)
• Re-run the prod superfluid fixture seeded by KEEP-438 (w6uj17db1zm3x2764v69p) after deploy and confirm it succeeds on-chain end-to-end (transaction hash, gas used, no revert)

Coverage note

The on-chain test file's "every declared action has at least one dispatch test" coverage assertion (line 358) ensures we can't ship a new action without a dispatch test. However, this PR's strengthened assertion exposes a wider opportunity: the existing pattern of expect(msg).not.toMatch(ENCODING_ERROR_RE) tolerates contract reverts as long as the calldata isn't ABI-mangled. That pattern hid the grant-flow-operator routing bug. Worth a follow-up to convert the other dispatch tests to positive-simulation assertions where the inputs allow it.

Out of scope

• The Sepolia fUSDCx test token's broken CFA proxy. We work around it; not our problem to fix the test token.
• Equivalent routing audit for other CFA-touching actions (create-flow, update-flow, delete-flow) -- they already route through cfaForwarder, so unaffected.
• Strengthening the other dispatch tests (see "coverage note").

[github-actions]

🧹 PR Environment Cleaned Up

The PR environment has been successfully deleted.

Deleted Resources:

• Namespace: pr-1167
• All Helm releases (Keeperhub, Scheduler, Event services)
• PostgreSQL Database (including data)
• LocalStack, Redis
• All associated secrets and configs

All resources have been cleaned up and will no longer incur costs.

[github-actions]

ℹ️ No PR Environment to Clean Up

No PR environment was found for this PR. This is expected if:

• The PR never had the deploy-pr-environment label
• The environment was already cleaned up
• The deployment never completed successfully