Remaining unbounded inbound resources in the packet path (split from #249)

[monkopedia-coder]

Split out of #249, which is now closed by PR #254. #249 fixed the primary hole — an unbounded, unsigned Content-Length driving a buffer allocation — and named three related items as explicitly out of scope. Those are recorded here so they are not lost inside a closed issue.

1. readFields accumulates headers without a cap. ksrpc-sockets/src/commonMain/kotlin/PacketUtils.kt:40-55 builds a LinkedHashMap with no limit on entry count, and calls readUTF8Line() without passing a length limit. A peer that never sends the blank terminator line grows the map indefinitely; a peer that sends one enormous line is bounded only by whatever readUTF8Line's default is, which is not stated at the call site.

2. Inbound binary chunks buffer through an unbounded channel. ksrpc-packets/src/commonMain/kotlin/PacketChannelBase.kt:520 uses Channel(Channel.UNLIMITED), so a peer that outruns the consumer is bounded only by heap. Unlike item 1 this is a legitimate design choice for throughput — the question is whether it should be configurable rather than unbounded.

3. maxSize reads like an inbound frame limit and is not one. PacketChannelBase.kt:55,70,245, default 16 KiB, governs outgoing chunking only. Every usage is on the send path. The name invites the assumption that inbound frames are bounded, which is exactly the assumption #249 disproved — worth either a rename or a KDoc line saying what it does not do.

None of these is the same severity as #249: that one let a single short header cost the host its heap before any content was read. These need a peer to sustain an attack, and 2 is arguably not a defect at all.

They are filed together because they share a cause — no inbound resource is bounded anywhere in the packet path — and because a fix for any of them wants the same decision made first: whether inbound limits belong in KsrpcEnvironment as configuration, which is a public API change, or as constants like MAX_CONTENT_LENGTH now is.

[monkopedia-coder]

Triaged -- keeping agent-workable, dispatching scoped. Recording the split here rather than only in the dispatch, because the line runs straight through this repo's public surface and ksrpc has four downstream consumers.

In scope now:

• Item 1, the readFields header cap. A bounded entry count plus an explicit length limit passed to readUTF8Line(), as constants in the same shape as MAX_CONTENT_LENGTH from Transports allocate a peer-controlled Content-Length with no bound or sign check #249. No public surface involved.
• Item 3, but only the KDoc half. A KDoc line on maxSize stating that it governs outgoing chunking and bounds nothing inbound. That is the part that costs nothing and removes the wrong assumption the issue identifies.

Out of scope, needing a call first:

• Item 2, the unbounded inbound chunk channel. The issue says it is arguably not a defect at all, and the useful version of the change is making it configurable rather than capping it -- which means a new knob on KsrpcEnvironment. Additive, so not breaking, but it is a public surface addition that four consumers inherit, and it should be settled as a configuration-design question rather than arrive as a side effect of a header-limit fix.
• Renaming maxSize. Breaking for anyone who sets it. The KDoc above is the non-breaking half of the same concern; the rename is not.

The body's closing line asks for "the same decision made first: whether inbound limits belong in KsrpcEnvironment as configuration, which is a public API change, or as constants like MAX_CONTENT_LENGTH now is." The scope above answers that for the two items that do not need it -- item 1 is a constant, matching what #249 already established in this same path -- and leaves the question open only for item 2, which is where it actually bites.