perf: bounded chunk candidate selection, O(1) commit lookups, per-pass light locks

[carabistouflette]

Type of change

• Block implementation
• Item implementation
• Command implementation
• Entity implementation
• Bug fix
• New feature
• Breaking change
• Refactor / code cleanup
• Performance improvement

Description

Chunk and light outbound efficiency:

• ChunkSender::collect_candidates selects the closest pending chunk positions with a bounded max-heap (vanilla PlayerChunkSender uses Comparators.least(maxBatchSize, distanceSquared)) instead of fully sorting the entire pending set: O(P log P) → O(P log N).
• commit_batch resolves prepared chunks through an FxHashMap built once per batch instead of a linear find per encoded chunk: O(B²) → O(B).
• The light publication pass defers sends to a per-player phase: each player's tracking view and chunk sender are locked once per pass instead of once per candidate chunk (up to 18 candidates per pass). World::send_deferred_light_updates owns the per-player resolution and get_light_packet_tracking_players is removed.
• Chunk light section matching switches to an FxHashSet when a section delta list holds more than 4 entries.

How this was tested

• New criterion kernel A/B chunk_candidate_selection (identical data, both algorithms in one binary): bounded heap 4.36 µs vs 9.55 µs full-sort at 512 pending chunks (2.2x) and 12.05 µs vs 65.69 µs at 4096 (5.5x), quota 64.
• cargo test -p steel-core --lib (2422 tests) pass; cargo clippy -r --all-targets clean. Light sends are grouped per player, so per-player packet order across different chunks changed; per-chunk light packets are independent and the client handles them in any order (same as vanilla's async sends).

Screenshots / logs

N/A.

Checklist

• Code builds w/o errors or warnings
• Self-reviewed the diff
• Docs updated (if applicable) — N/A
• No leftover debug code / comments

Additional notes

• Env: Linux, Rust nightly, Minecraft protocol 776 (0.15.2+mc26.2).

[chocodev11]

idk if commit_batch iss really matter here and send_deferred_light_updates feel very, very risky