Upgrade crates for January 2026

[patowen]

This PR updates the following crates:
criterion: 0.5 -> 0.8
hecs: 0.10 -> 0.11
nalgebra: 0.33 -> 0.34
png: 0.17 > 0.18
prost: 0.13 -> 0.14
prost-build: 0.13 -> 0.14
rcgen: 0.13 -> 0.14
redb: 2 -> 3
toml: 0.8 -> 0.9
whoami: 1 -> 2

It also replaces bincode 1.2.1 with postcard 1.0.4, as bincode is no longer being maintained, and postcard was already in use in this codebase.

[patowen]

@Ralith, it looks like bincode is just used in codec.rs for quinn. The replacement suggestions are wincode, postcard, and rkyv.

As you have worked extensively on quinn, I expect that you have thoughts on what libraries should be used for networking, so I wanted your thoughts before looking into making any kind of switch.

[Ralith]

I'm not familiar with wincode, but from the name I assume it's a straightforward fork of bincode 2. If bincode 2 isn't too big a break itself, then it might be the easiest. However, there is strong evidence that postcard will have long-term maintenance, and it's technically sound, so I would lean towards it, especially since our use is isolated enough that migration should be trivial regardless.

rkyv solves a substantially different problem than the other two, so I wouldn't consider migrating to it as part of routine maintenance.

[patowen]

postcard seems to work well. Thank you for the suggestion. I had gotten tripped up by assuming that the tag with the length of each message was 4 bytes instead of 3, and the resulting parsing error ended up not leaving any logs, tripping me up further.

For the latter issue, I bundled additional logging in this PR in case something like this happens again.

[patowen]

Given the fact that you've approved these changes, and my further changes did not cause the actual code to change (just the commit history), I will go ahead and merge after the checks pass.

I thought about pressing merge button now to double-check (while the stakes are low) that these checks are still required, but I'm pretty sure they aren't anymore because of #461 (comment). I'm a bit worried that this is just a hard GitHub limitations where merge checks cannot be source controlled and depend on which files are being modified.