Third of the "day planner must not degrade as history accumulates" series,
after #3564 (outbox → table) and #3566 (priority claiming).

The problem

Opening a day loaded every capture and every day-status event the
owning agent had ever recorded, then filtered them in Dart:

• day_agent_provider.dart — getEntitiesByAgentId(ownerId, type: capture)
  for both owners, no limit, day-filtered afterwards. Its own comment conceded
  "an owner can hold many days' captures (the coordinator always does)".
• day_agent_persona_provider.dart — every dayStatusEvent for the owner,
  filtered to the day in Dart. Status events drive the activity indicator and
  are the fastest-growing entity type in the feature.

Both are Riverpod providers on the main day surface, so the cost of opening one
day grew with the user's entire history.

Severity was not uniform, which is worth stating: a day_agent:<dayId> is
self-limiting by construction — it holds one day's rows and then goes cold
forever. The coordinator is the accumulator, and it owns every pre-cutover day
(day_agent_service.dart leaves those under the monolith permanently).

Cause

The projected subtype column. capture stored the capture's own id —
redundant with the primary key — and dayStatusEvent stored its status name,
so neither could serve a day-scoped lookup. Meanwhile dayPlan, daySummary
and dayDirective already stored the day and were served by
idx_agent_entities_agent_type_sub.

Neither old value was used as a query key anywhere, so repurposing them is
safe. subtype is a locally-derived projection, not part of the synced
payload, so a device on an older build keeps deriving its own — no sync skew.

What changed

• entitySubtype writes the day workspace for both types; the two providers
  read through getEntitiesByAgentIdAndSubtype.
• localDay/dayAgentIdForDate move to lib/classes/day_plan.dart beside
  dayPlanId, so the agent persistence layer can derive a capture's day
  without depending on a feature package.
• A capture with no explicit dayId (synced from a peer predating it) derives
  one from capturedAt in local time — the same rule captureDayId
  applies on read — so legacy rows land on the right day instead of needing a
  Dart-side fallback scan.
• Schema v17 backfills existing rows through that same Dart projection rather
  than a SQL json_extract update. That is deliberate: the local-time
  derivation cannot be expressed faithfully in SQL, and a backfilled value that
  disagreed with the writer would silently drop rows out of their day.
  Undecodable rows are skipped rather than aborting the upgrade.

Testing

1902 daily_os_next + 5066 agents tests pass; analyzer and formatter clean.

New coverage: day-scoped reads return only the requested day; a legacy capture
with no dayId is found by its derived day; an explicit dayId wins over the
derivation (a capture recorded after midnight can belong to the previous
planning day); and the conversion tests now pin the day subtype for both types.

No CHANGELOG entry — no runtime behavior a user would notice beyond the day
view getting cheaper.

Still open in this area

_plannerOwnsDay (day_agent_service.dart) still scans the planner's whole
capture history via getCaptureEventMetaByAgentId on every day-agent
resolution, which runs ahead of both providers. It is now a one-line query
change on top of this index and I left it out to keep the schema migration
reviewable on its own — happy to fold it in here if you would rather.