quiet-hours: the page ignores the quietUnchecked flag the doc promises, and the summary says "team clock" where the check uses the task's own zone #1199

Two non-blocking notes from the #1193 review (#1166, merged as 7d2c0350e3), kept as one card because both live in the same quiet-hours section and one diff settles both. Anchors are on main 7d2c0350e3.

1. quietUnchecked is computed twice, and the page never reads the view's copy

• core/src/host/schedules.js:327 puts the flag on the view: { available: true, tasks, quietHours, ...(unchecked ? { quietUnchecked: true } : {}) }.
• core/src/client/schedules.js:263 ignores it and recomputes its own predicate from the task list: const unchecked = view.tasks.some(task => task.kind === 'every' || task.kind === 'cron'), rendered at :292-293.
• docs/subsystems/core-host.md:382 says "The view carries quietUnchecked: true … and the page renders that as one line" — the page renders its own computation, not that field. The sentence describes wiring that does not exist.

Why it matters beyond tidiness: the two predicates are not the same shape. The host's carries the quiet-hours guard as well; the client's is a bare some(...) combined with quiet.on at render time. Today they agree by coincidence of construction, and after any change to either — or any view state where tasks and flag disagree — the page and the doc drift apart with nothing red.

Fix (pick one, say which in the PR): the page reads view.quietUnchecked and the client-side some(...) goes away (preferred: the host already owns the state, and the doc is then true), or the host stops emitting the flag and core-host.md:382 says the page computes it. One source, one sentence.

Case: a view whose tasks contain no every/cron task but whose quietUnchecked is true (a deleted repeat task between two polls is the realistic route) — with the page reading the field the line renders; with today's client it does not. That assertion must fail on today's code.

2. core-host.md:378 says "the team's own clock"; the check uses each task's own zone

:378 — "A window in the team's own clock that a new or edited task must fall outside". :381 and the code say the opposite for the kinds where it matters: a one-shot at is read in the zone the form sends, and daily/weekly carry their own wall clock and zone with the time, so the comparison is against the task's clock. The acceptance item for #1166 said "the wall clock", so the code is right and the summary sentence is loose. One sentence here, matched to :381; no code change.

Acceptance

1. One computation of the repeat/cron warning; the other is deleted, not left dormant.
2. The assertion in 1 fails on today's tree and passes after, and no other test changes.
3. core-host.md:382 is true afterwards; :378 no longer claims a single team-wide clock where the check reads the task's own zone.
4. node --test core/test/schedules.test.js core/test/schedules-client.test.js green; patches mirrors and build-client --check as usual (this touches core/src/client).
5. One PR, and it is the same diff for both halves — they are in the same section, not two topics glued together.

Not in scope: the suppressed count and any mute at delivery time (blocked on DSH, recorded on #1166).