Add runtime bounds guards to assert-only public entry points

[gafferongames]

Summary

Closes the Debug-vs-Release memory-safety gap in the public API: functions taking max_clients or a client_index validated them with netcode_assert only, which compiles out under NDEBUG. In release builds, netcode_server_start( server, 500 ) wrote past the per-client arrays, and the assert-only accessors (netcode_server_client_user_data, netcode_server_next_packet_sequence, netcode_server_client_loopback, the loopback connect/disconnect/process functions, netcode_server_send_packet, netcode_server_receive_packet, netcode_server_disconnect_client) read or wrote out of bounds for an out-of-range index.

• Every such entry point now pairs its asserts with runtime guards that return cleanly (same belt-and-suspenders pattern the send paths already used for packet sizes). netcode_server_start logs an error for out-of-range max_clients.
• Guards are ordered before any assert that indexes an array, since custom assert handlers may continue past a failed assert.
• Loopback packet sizes are now guarded to (0, NETCODE_MAX_PACKET_SIZE], consistent with the network path's rejection of zero-byte payloads.
• New test_runtime_guards (suite is now 38 tests) installs a continuing assert handler so the guards are exercised in Debug builds too, and verifies out-of-range arguments return cleanly without starting/connecting/corrupting anything.

Test plan

• Local macOS: Release, Debug, and ASan+UBSan builds all pass the full suite including the new test
• CI green on all 9 jobs

🤖 Generated with Claude Code