Add fuzz testing for token-swap offer matching

[christabel888]

Context: analytics/src/fuzz_tests.rs and governance/src/fuzz_tests.rs already exist and establish the pattern -- token-swap has neither a fuzz harness nor fuzz_tests.rs.

Where:

• token-swap/src/fuzz_tests.rs (new, mirror the structure of analytics/src/fuzz_tests.rs)

What to do:

• Add fuzz targets covering token-swap's offer matching (partial fills, price edge cases, matching against a cancelled offer).
• Reuse whatever fuzzing harness/crate analytics/src/fuzz_tests.rs and governance/src/fuzz_tests.rs already depend on rather than introducing a second one.

Suggested approach:

1. Read analytics/src/fuzz_tests.rs and governance/src/fuzz_tests.rs first -- copy their harness setup (fuzzing crate, entry-point structure, corpus/seed strategy) rather than picking a different fuzzing approach for token-swap.
2. Identify the 2-3 functions in token-swap/src/lib.rs most likely to have input-dependent edge cases -- for this crate, that's specifically offer matching -- partial fills, price edge cases, matching against a cancelled or already-filled offer.
3. Write fuzz targets that generate arbitrary-but-valid-shaped inputs (amounts, addresses, timing) and assert on invariants (e.g. "total funds in equals total funds out", "never panics regardless of input") rather than fuzzing for panics alone.
4. Run it for a fixed budget (document how long, e.g. "ran 10 minutes locally, 0 crashes") and report that in the PR -- an unbounded fuzz run isn't reproducible or reviewable.

Watch out for:

• A fuzz harness that never fails isn't necessarily proof of correctness -- make sure your generators can actually produce the adversarial inputs you care about (e.g. zero amounts, max-value amounts, same address for both sides of a trade), don't just fuzz uniformly random valid-looking data.
• If you do find a real panic/bug, that becomes its own fix -- don't silently work around it inside the fuzz harness.

Definition of done:

• token-swap/src/fuzz_tests.rs exists and runs
• At least one previously-unhandled panic/edge case found and fixed, or explicitly confirmed none exists after a fixed fuzzing budget