docs: update contributor credits and add multi-agent billing FAQ

[belangertrading]

Updates the contributor table to reflect the full scope of diagnostic work across issues #4, #6, #7, #12, and #23 — as acknowledged in #23 (comment).

Also adds a FAQ entry for multi-agent session-level billing classification, based on the debugging trail documented in #23. Common gotcha for anyone running agent orchestrators through dario.

[askalf]

Thanks for the PR. The contributor row update is accurate and I'm happy to take it. Declining the FAQ hunk, and I want to explain the reasoning rather than just say no.

The FAQ as drafted prescribes a single approach — a subprocess-based bridge — as THE workaround for multi-agent session-level classification. I don't think that holds up as general advice for dario's audience for three reasons, all of which come from the diagnostic work you did in #23 itself:

First, your own finding was that Anthropic's classifier operates on per-account behavioral aggregates — token volume, request frequency, conversation depth on each OAuth session. A bridge that shells to claude --print concentrates 100% of a team's agent workload on one CC subscription on one machine. That's the behavioral shape the classifier is tuned to detect. It works today because the classifier isn't tightened enough to catch every high-volume single-account session. But your own data showed the classifier is tightening, not loosening. Recommending a single-account bridge as the workaround in our README is recommending the exact pattern the classifier is hunting for.

Second, a single CC subscription has one 5h rolling window and one 7d rolling window shared across every agent running through the bridge. Busy day = hard stop until it refreshes. This isn't a classifier problem, it's an architectural ceiling. Bridges can't scale past one subscription by design.

Third, a single-machine, single-account, single-binary setup is one machine reboot, one ISP hiccup, or one Anthropic-side account action away from total shutdown. That's acceptable for some workloads and a production liability for others.

None of this is an argument against your specific deployment — you've clearly tuned your stack around those tradeoffs and it works for you. It's an argument against framing your specific approach as THE workaround in a general README FAQ. Readers hitting dario's docs have a range of workload shapes, and a range of right answers exists depending on that shape:

• Reducing tool count and session length (which you yourself did to stay under the threshold)
• Rotating sessions more frequently
• Subprocess-based bridges for workloads that fit the single-account tradeoffs
• Multi-account pools that distribute load across independent OAuth sessions so no single account concentrates the behavioral signal

I'd be open to a FAQ entry that presents the landscape rather than a single prescription. If you want to rebase this PR with just the contributor row (which is accurate and I'll merge as-is) and propose a separate PR with the landscape framing, I'll look at that on its merits. If you'd rather just drop the FAQ hunk and keep the contributor update, that works too.

[askalf]

Thanks for the revision — contributor row looks accurate, merging.