Validate client input to prevent panics from malformed transactions

A malicious or buggy client could send transaction fields with the wrong
length and trigger runtime panics (slice/index out of range, slice-to-array
conversion, nil deref) in the parsing and handler code. These were caught by
the connection-level recover, so they dropped the client connection and dumped
a stack trace to stdout rather than crashing the process, but they are still
incorrect behavior, a log-flood vector, and a latent crash if the recover
scope ever changes.

Fix at the source and harden the safety net:

- Add ClientIDFromBytes / ChatIDFromBytes helpers that return ok=false on a
  length mismatch, and use them in the transaction handlers instead of direct
  [2]byte(...) / [4]byte(...) conversions on field data. Nil-check ClientMgr.Get
  results, and length-guard FieldOptions and the HandleUpdateUser sub-field
  header. Malformed input now yields an error reply (or a clean no-op for
  reply-less handlers) instead of panicking.
- Bounds-check FileResumeData.UnmarshalBinary (header length and fork count)
  and guard the ForkInfoList[0] accesses against an empty list.
- Bounds-check FlatFileInformationFork parsing (reachable on upload): validate
  the fixed header, name, and comment lengths, and fix a latent 72+nameSize
  uint16 overflow. Route Write through UnmarshalBinary.
- panic.go: stop printing stack traces to stdout (keep structured logging) so a
  client cannot flood stdout by repeatedly triggering a panic.
- handleTransaction: recover per-transaction so one malformed request no longer
  tears down the whole client connection.

Adds tests for the new helpers, the hardened resume-data and flat-file-object
decoders, and handler-level malformed-ID handling.

0 files changed, 0 insertions, 0 deletions