fix(hunty-core): remove O(n) scan in add_player_to_list on progress save

[JesseJohn7]

Closes #1049

Problem

save_player_progress runs on every answer, hint and claim and calls
add_player_to_list. When the player's existence marker was present, the
function looped over indices 0..count reading each entry until it found the
player. Every submission therefore cost O(players) storage reads, making large
hunts effectively unplayable.

Fix

• add_player_to_list now trusts the existence marker: if it is set, the
  function returns immediately. No scan.
• Applied the same change at the second occurrence (storage.rs ~L1456-1483).
• The marker is written in the same code path that appends to the list, so it
  is an accurate signal of membership.

Benchmark

Added bench_save_progress_500_players in test.rs. It registers 500 players,
then measures the CPU instruction cost of a single progress save for the
last-registered player (worst case for the old implementation) and asserts it
stays under a fixed ceiling.

	CPU instructions
Before
After

Testing

• cargo test -p hunty-core passes
• cargo fmt / cargo clippy clean

Acceptance criteria

• Trust the existence marker and skip the scan
• Benchmark with 500 players