fuzz: avoid panics in append_function on generic functions (fixes #21)

[Gy-Hu]

Closes #21.

The fuzzer previously aborted when probing generic functions whose fixed and derived type arguments disagreed (crates/movy-fuzz/src/mutators/sequence/append.rs:113). The sibling PartialFound branch already handles the same class of conflict by returning None, so match that pattern here.

Relax four adjacent fallible sites to the same debug! + return None pattern so the fuzzer can skip rather than crash when:

• the function identifier is not in the ABI map (get_function miss)
• gen_input_arg fails to synthesise an initial value (two call sites, one per ConstructResult branch)
• a balance/coin parameter does not substitute to a struct

Convert the two pattern-match else arms that guard just-constructed MoveSequenceCall::Call values to unreachable!, which better reflects the invariant.

Validation

Rebuilt movy release and reran the saved flash_lender benchmark:

./target/release/movy sui fuzz --seed 1 --time-limit 5 \
  --output target/benchmarks/movy-flash-fuzz --force-removal \
  --checkpoint 210000000 \
  --locals target/benchmarks/sui-mainnet-v1.60.1/examples/move/flash_lender

Output matches the pre-change run: corpus: 19, objectives: 1, executions: 3051 with the same ProceedsOracle finding. The change is a strict relaxation of panic paths; no existing behavior is altered on non-panicking inputs.

Test plan

• cargo build -p movy-fuzz --release — clean
• cargo build -p movy --release — clean
• flash_lender benchmark reproducible (identical corpus / objectives / executions / crash-fb)
• End-to-end reproduction of issue panic! in append.rs:113 on generic functions #21 (the report did not include a minimal package; if reviewer has one, happy to add it as a regression test)

[Gy-Hu]

Thanks for checking.

I took another look at v1.65.2-pending. If the goal is to cover the behavioral issue from #23 / #21, I don’t think it is fully covered yet. In the current branch, crates/movy-fuzz/src/mutators/sequence/append.rs still has the same panic path for conflicting type arguments:

panic!("Conflicting type arguments for index {}", i);

and the adjacent unwrap/panic paths that #23 relaxed also still seem to be present. Maybe there is another change in v1.65.2-pending that makes this path unreachable, but I could not confirm that from the code.

For #24, most of it is typo/public identifier cleanup, so I understand if that is not the main concern for this branch. I did notice those typo fixes are not included yet, but they can be handled separately if you prefer.

Since these PRs don’t seem to be aligned with the current development focus, I’ll close them for now. If they become useful later, I’m happy to reopen/rebase/split them as needed.