Adaptative concurrency improvements - fair sharing expectation

While implementing adaptative concurrency on huggingface.js (https://github.com/huggingface/huggingface.js/pull/2350), fable 5 pointed out potential avenues for improvement in xet-core:

> Ours is much simpler (throughput-delta AIMD), which fits a JS lib; but two findings may be useful **upstream for xet-core**:
>
> 1. **No byte/memory budget**: xet-core's controller is purely permit-count based. With v2 entries up to a whole xorb (~64MB compressed) and up to 64 permits, worst-case buffered memory is unbounded by anything except the permit count. Deriving a byte budget from the reconstruction (entry sizes are known upfront) would give a hard memory envelope — particularly relevant for `hf_xet` on small machines.
> 2. **Zero-error saturation**: xet-core's model treats linear RTT growth with concurrency as *expected fair sharing* (`x_eff = size × N`), so on a capped link it plateaus via the 60s target-RTT ceiling rather than detecting that aggregate goodput stopped improving. Our US-VPS data shows fixed high concurrency actively hurts on such links while all requests succeed. A cheap aggregate-goodput probe ("did the last +1 increase total throughput?") could let it settle lower, reducing both client contention and server connection load.

Especially `2.` - fair sharing expectation

Start with the adaptive-concurrency implementation discussed in huggingface.js PR #2350, then inspect xet-core’s permit-count controller and its fair-sharing assumptions. Determine how to evaluate aggregate goodput as concurrency changes on capped links; done means a decided design and tests showing the controller settles lower when additional concurrency no longer improves throughput.

Written by the indexing model from the issue text.