Fixes #6797

Summary

• Tick expressions containing date variables ($now, $today, etc.) used as filter
  predicates — e.g., WHERE now() IN '$now-100s..$now' — resolved $now once at
  compile time and cached the resulting interval as static timestamps. On repeated
  execution of a cached SQL statement, the interval never updated, causing the filter
  to return 0 rows once now() moved past the originally computed range.
• The interval model path (used for tables with a designated timestamp) was already
  fixed in fix(sql): compile tick expressions with date variables into IR for zero-parse evaluation when executing caches SQL statements #6780 to compile such expressions into IR via CompiledTickExpression.
  The filter function path in InTimestampTimestampFunctionFactory was not updated
  and still used the static EqTimestampStrConstantFunction.
• The fix detects date variables in constant tick expression strings and routes them
  through CompiledTickExpression, which re-evaluates the interval from IR on each
  execution via init().

Test plan

• New test testNowInTickExprWithDateVariableReevaluatesOnCachedExecution compiles
  WHERE now() IN '$now-100s..$now' once, executes the factory at T1 (expects 1 row),
  advances now() by 200s, and re-executes (expects 1 row again)
• All existing InTimestampTimestampTest tests pass (no regressions in constant and
  bind-variable interval paths)

🤖 Generated with Claude Code