the hardcoded 400kb/s was a stability compromise and the previous knob
just moved the guesswork to operators: they had to hand-measure each
sfu's policer knee by ramping until stalls. replace both with a
delay-based aimd controller that finds the knee at runtime.
the sfu policer queues before it drops, so kcp's smoothed rtt inflates
ahead of the throughput collapse from #95/#107. the pacer folds one
srtt sample per writer tick: probe the rate up additively while delay
sits near the path baseline, back off multiplicatively once it
inflates. it settles just under the per-sfu knee on its own, both on
the client->server writerLoop and each server->client peer pump.
vp8.max_bytes_per_sec is now just the probe ceiling (default 1mb/s);
a fresh session still starts from the old 400kb/s operating point so a
healthy path only ramps up. no per-service hand-tuning left.
refs #107
the pacer was pinned at a hardcoded 400kb/s stability compromise, so
operators could not reach their sfu's real throughput ceiling without
recompiling. the options.maxbytespersec knob already existed but was
never wired from yaml. plumb it through config -> session -> transport,
keeping 400kb/s as the conservative default.
refs #107
neuronori