NodeFilter's created_after/created_before/modified_after/modified_before fields are silently dropped by the only code that consumes them #2978

Problem

No current user or developer is actually affected — every real call site (ops, daemon, agent tools) ignores these fields entirely, and date-range querying for agent/CLI use is already served correctly by a separate, working mechanism (QueryService metadata filters). This is a latent/dead public-API trap rather than an active bug someone is hitting today, which is why it was revised down from the sweep's original "high."

Root cause

NodeFilter (packages/core/src/models/node.rs:275) declares these four temporal fields plus with_* builders, and the type's own doc example advertises "tasks created in last 7 days" as a use case. But NodeService::query_nodes, the only place a NodeFilter becomes a real query, builds its NodeQuery by explicitly listing forwarded fields — the four temporal fields are never read anywhere in the crate, and NodeQuery itself has no representation for them at all, so there's nowhere to put them even if forwarded. Every real call site that constructs a NodeFilter (ops, daemon, agent) never sets these builders. Meanwhile, the actual agent/CLI-facing date-range query need is already served by a separate, correct path: ops/query_ops.rs::execute_query_nodes → QueryService, whose build_metadata_filter correctly supports created_at/modified_at comparisons as real SQL predicates.

Suggested fix

Delete the four unused fields and builders from NodeFilter per this repo's no-dead-code policy, since date-range querying is already served by QueryService's metadata filters — or wire them into NodeService::query_nodes's NodeQuery construction if a low-level consumer is genuinely planned.

Found via the 2026-09-25 full-repo code sweep (finding #32 of 84 in CODE_SWEEP_FINDINGS_2026-09-25.md). Severity: medium. Category: broken.