Fix getbondinfo byte-order mismatch on bond_key

[USCMig]

Summary

getbondinfo decoded its bond_key hex parameter with a plain, non-reversing hex parse (Vec::from_hex directly into [u8; 32]), while every other place a bond key / pubkey travels through the RPC layer — e.g. the unique_public_key/bond_key fields used by wallet_staking_action — goes through PubKeyID's Serialize/Deserializeimpls, which byte-reverse for display (matching the usual txid/hash display convention). The mismatch meantgetbondinfoalways looked up the wrong 32 bytes for any key produced by the normal staking flow, so it silently returnednull` for bonds that were genuinely active and committed on the best chain.

Fix: type the bond_key parameter as PubKeyID instead of a raw String, so it automatically follows the same reversed-hex convention as the rest of the staking RPC surface (wallet_staking_action's RetargetDelegationBond, BeginDelegationUnbonding, WithdrawDelegationBond all already use PubKeyID for their bond_key fields).

How this was found

Created a real CreateNewDelegationBond staking action via wallet_staking_action, confirmed via getblock/getblockhash that the resulting transaction was mined into a canonical, non-reorged block, yet getbondinfo returned null for the exact bond_key (unique_public_key) string returned by that same RPC call. Manually byte-reversing that hex string before querying getbondinfo returned the correct bond (amount, status: Active, last_action_height matching the confirmed block height) — confirming the byte order, not the underlying bond tracking, was the bug.

Test plan

• cargo build --release --bin zebrad succeeds cleanly against main with this change
• Live-verified against a running devnet node: the previously-null getbondinfo lookup for a real, confirmed bond returns correct data once byte order matches the PubKeyID convention
• Would appreciate a maintainer double-checking there's no external tooling relying on the old (incorrect) non-reversed byte order for this specific RPC