Never place outstanding work before the present moment

[SociableSteve]

Closes #82.

What changed

scheduleDay in web/surfaces/Dashboard.tsx walked the plan's entries through the whole
working window from the top, regardless of what time it was, so a plan read mid-afternoon
still drew an unfinished entry as though the day had not started, entirely behind the day
bar's now marker. It has moved into src/domain/plan.ts, pure and generic over the entry
shape (SchedulableEntry, an estimate and a done flag), and its signature is now
scheduleDay(entries, freeIntervals, now).

Completed and outstanding entries are placed in two separate passes rather than through one
cursor floored at now:

1. Completed entries (entry.done) are placed first, in their own rank order, from the top
   of the free intervals, exactly as the whole plan used to be walked. Completed work is a
   fact about where it happened, and this pass never moves it.
2. The minutes that pass consumed are taken out of the free intervals, and whatever remains
   is floored at now.
3. Outstanding entries are then placed, in their own rank order, into what that leaves.

A single shared cursor floored at now was not enough on its own: ranked ahead of an
outstanding entry, a completed one would be dragged into the future along with it. Doing
the subtraction before the floor is also what keeps a completed entry's block that
straddles now from being handed to an outstanding entry: the minutes it consumed are
unavailable whichever side of now they land on.

Gaps are only the free time still ahead of now: elapsed free time is not drawn on the day
bar's track at all (no new track kind, per the plan this followed) and is not offered as
slack in the agenda. An outstanding entry with nowhere left to go past now still comes
back with startsAt: null and renders untimed, exactly as the existing unschedulable case
already did.

Specs and docs

Spec, then docs, then code, in this commit:

• docs/specs/05-daily-plan.md: a new "Placing the plan against the clock" section states
  the rule (it belongs here, not in spec 08, since the day bar and the agenda are two
  renderings of one placement), and criteria 21 to 24 are appended.
• docs/specs/08-api-and-ui.md: criteria 41, 43 and 47 are extended in place to describe
  the same walk now that it also depends on the present moment. No new criteria there,
  per the agreed scope: the decision moved to spec 05 rather than growing spec 08.
• docs/using.md: one sentence added to the day bar bullet, saying elapsed time is not
  drawn as free either.
• README.md, docs/content-policy.md and docs/plan.md checked and left alone: no tool,
  content level or configuration changed, and this is a bug fix within an already-landed
  milestone rather than a new one for docs/plan.md to record.

Testing

Test-first, under test/domain/plan.test.ts alongside the existing plan tests, driving
scheduleDay directly with a fixed now rather than through a rendered fixture. Nine new
tests, one or more per new criterion:

• an outstanding entry late in the window is placed at or after now, never before it
  (21)
• a completed entry keeps its own placement once now has moved past it, and is not
  dragged forward (22)
• a done entry claims the top of the window even when it ranks after an outstanding one
  (22)
• a done entry's block straddling now does not let an outstanding entry start inside it
  (23)
• a free interval entirely behind now yields no gap at all, and one straddling now is
  trimmed to its future part (23)
• an outstanding entry with nowhere left to go past now comes back with startsAt: null
  rather than being dropped, and the genuinely-too-small remainder is still reported as a
  gap (24)
• now before the window opens reproduces the old single-pass walk exactly
• now after the window closes places no outstanding work, while a done entry still keeps
  its own placement

All 79 existing tests in web/Dashboard.test.tsx pass unchanged: every fixture in that
file that sets now explicitly does so against a calendar with no free intervals, and
every other test uses the default fixture where now equals the window's start, so
nothing in the existing suite had elapsed time to expose the old defect. No real-clock
usage was found in that file either, so nothing needed pinning there.

Checks run, in this order, over the whole project:

• npm run lint: clean.
• npm run typecheck: clean.
• npm test: 2933 tests pass across 136 files.
• npm run build: clean.
• npm run build:site: clean (needed npm install first in this fresh worktree, for a
  font package declared in package.json but missing from node_modules; unrelated to
  this change, and neither package.json nor the lockfile changed).

Notes

While extending spec 08's criterion 47, I found its prose was already slightly stale in a
way this change makes worse: it explained the legend's four figures not summing exactly to
windowMinutes as a rounding artifact only. With elapsed free time now undrawn entirely,
that gap can be much larger than a rounding error on a day with time behind it, so I
extended the criterion (and the matching code comments in Dashboard.tsx) to name both
causes rather than leave the older, now-incomplete explanation standing.

I did not touch the pre-existing (and, as far as I can tell, still present) edge case
where a no-estimate entry can be offered a placement sitting exactly on an interval's
boundary rather than genuinely inside it: it predates this change, is unrelated to the
present-moment rule, and fixing it was not part of what was asked.