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.

1 files changed, 22 insertions, 0 deletions

diff --git a/hotline/decode.go b/hotline/decode.go
new file mode 100644
index 0000000..385bc07
--- /dev/null
+++ b/hotline/decode.go
@@ -0,0 +1,22 @@
+package hotline
+
+// ClientIDFromBytes converts client-supplied bytes to a ClientID, returning
+// ok=false if the input is not exactly the expected length. Use this instead of
+// a direct [2]byte(...) conversion on field data, which panics on a length
+// mismatch.
+func ClientIDFromBytes(b []byte) (id ClientID, ok bool) {
+	if len(b) != len(id) {
+		return id, false
+	}
+	return ClientID(b), true
+}
+
+// ChatIDFromBytes converts client-supplied bytes to a ChatID, returning ok=false
+// if the input is not exactly the expected length. Use this instead of a direct
+// [4]byte(...) conversion on field data, which panics on a length mismatch.
+func ChatIDFromBytes(b []byte) (id ChatID, ok bool) {
+	if len(b) != len(id) {
+		return id, false
+	}
+	return ChatID(b), true
+}