[harper-joseph]

Docs and comments only; no behavior change. Corrects a number I introduced in #100.

The error

The ~9.5% of fleet throughput figure in the README, the render.orphanSweep description and the orphanSweep.js module comment came from ~40,400 schedule rows ÷ 6h nominal interval = ~6,740/hr against the 71,289/hr ceiling.

That assumes the orphans achieve their nominal 6h cadence. A backlogged queue cannot give them that — and this cluster was ~8.2h behind.

The model

nextRenderTime is stamped at completion, not at the original due time. So a row rendered L behind its due time has its next render set interval after that: the realized cycle is interval + L, and the lag is carried into every subsequent cycle rather than caught up.

At L ≈ 8.2h, orphans on a 6h interval run a ~14h cycle:

	claimed	actual
orphan render rate	6,740/hr	~2,900/hr
share of 71,289/hr ceiling	9.5%	~4%

Roughly half what was stated.

But the ceiling is the wrong denominator anyway

While the fleet is saturated, what matters is the orphans' share of the work actually being completed. Stretching every class by the same interval + L (PDP 48+8.2 ≈ 56h, catalog 6+8.2 ≈ 14h):

• PDP ~27,200/hr, real catalog ~5,400/hr, orphans ~2,850/hr → ~35,500/hr total
• orphans ≈ 8% of it

So the original figure was roughly right for share of work being done, but reached by the wrong route and stated against the wrong denominator. 8% is what deleting them frees, and the benefit compounds slightly: removing that work shortens L, which shortens interval + L for every remaining class.

All three sites now document the interval + lag model itself, not just the corrected number — dividing rows by interval is the natural way to size this, and it's wrong whenever there's a backlog.

664 tests passing, lint and format clean.

[gemini-code-assist]

Code Review

This pull request updates the documentation and comments in README.md, configSchema.js, and orphanSweep.js to provide a more precise calculation of the throughput cost of orphan schedule rows. It explains that because nextRenderTime is stamped at completion, any lag L extends the cycle to interval + L, revising the previous flat estimate of ~9.5% throughput to ~4% of the throughput ceiling or ~8% of actual completed work under saturation. There are no review comments, and I have no additional feedback to provide.