Allow using secret to collect rewards

[illuzen]

• new --secret arg for collect-rewards (could be easily extended to other commands)
• it conflicts with both --wallet and --mnemonic

[n13]

Review

Overall this is a clean change — the WormholeCredential enum is a good abstraction and the cleanups in collect_rewards_lib.rs (dropping the duplicate parse_secret_hex wrapper, lifting secret parsing out of the per-transfer loop) go in the right direction. A few things worth tightening before merge:

1. Leftover duplicate compute_wormhole_address inside the proof loop

src/collect_rewards_lib.rs still recomputes the wormhole address per transfer:

// inside `for transfer in selected_transfers.iter()`
let computed_wormhole_address =
    wormhole_lib::compute_wormhole_address(&wormhole_secret_bytes)?;

The top-level match already produced wormhole_address_bytes with the identical value, so this hashes the secret once per transfer for nothing. The loop should just reuse wormhole_address_bytes.

2. The new tests don't actually exercise the new code paths

All 6 new tests are indirect — they call parse_secret_hex_str and wormhole_lib::compute_wormhole_address directly rather than the new match arms in collect_rewards. test_wormhole_credential_secret_address_derivation even says so: "Now simulate what WormholeCredential::Secret does" — it re-implements the logic rather than invoking it. If someone broke the real match arm (e.g. fed the wrong argument into compute_wormhole_address), the test would still pass.

Concrete gaps:

• No test that WormholeCredential::Secret inside collect_rewards produces the expected (address, address_bytes, secret_bytes).
• No equivalence test: deriving a secret from a mnemonic via HD and feeding it back as Secret { hex } should yield identical (address, secret_bytes). This is the invariant that makes the two variants safely interchangeable.
• The HD derivation failed error path isn't touched.

The cheap fix is to extract the branch logic into a small helper like pub fn resolve_credential(&WormholeCredential) -> Result<(String, [u8;32], [u8;32])> and write the tests against that helper. Then they exercise the actual production code.

3. The clap mutual-exclusion — the whole point of the PR — has no guardrail

The PR description says "it conflicts with both --wallet and --mnemonic" but nothing tests the required_unless_present_any or the three conflicts_with_all pairs. A regression that silently drops one of these attributes would go unnoticed. A thin #[derive(clap::Parser)] wrapper around WormholeCommands plus try_parse_from catches it in ~30 lines.

---

I've opened #94 against this branch implementing all three. It adds:

• resolve_credential helper + reuse in the proof loop (fixes the redundant compute).
• 7 direct tests of resolve_credential (both branches, error paths, and the mnemonic↔secret equivalence).
• 3 clap parsing tests covering the required-unless-present and all three conflicts pairs.

Test results: 88 passed, 0 failed, clippy clean.

Feel free to merge #94 into this branch (or cherry-pick) before merging to main.

[n13]

Can be merged after #94 is merged