fix(worker): exclude pre-creation checks in today uptime

[Lumexia]

Summary

Fixes inconsistent uptime semantics for newly created monitors in public/status.
The synthetic current-day uptime calculation now clamps each monitor’s range start to max(dayStart, monitor.created_at) so pre-creation time is
not counted as unknown/unavailable.

Changes

• Updated computeTodayPartialUptimeBatch in apps/worker/src/public/status.ts:
  • Added created_at to monitor input.
  • Computed per-monitor monitorRangeStart = max(rangeStart, created_at).
  • Clamped downtime and unknown interval calculations to per-monitor range.
  • Returned zero/null totals if monitor is created after current range end.
• Updated call site in computePublicStatusPayload to pass created_at.
• Added regression test in apps/worker/test/public-status.test.ts:
  • clamps synthetic today uptime to monitor creation time for newly created monitors.

Test Plan

• pnpm lint passes
• pnpm typecheck passes
• pnpm test passes
• Manually tested:
  • Created a new monitor while existing monitors were already present.
  • Opened public status page and inspected today’s uptime tooltip for the new monitor.
  • Verified today’s uptime window is effectively clamped to monitor creation time:
    • Pre-creation period is not counted as unknown.
    • Uptime no longer drops to an artificially tiny value immediately after creation.
  • Confirmed existing monitor status/uptime display behavior remains unchanged.
  • 

Related Issues

Closes #28

[VrianCao]

感谢啊！！一直想修这个，一直被耽搁了结果被我忘记了！
说的是对的，新的 Monitor 建立后应该从下一计时点开始计入数据，而非直接开始，否则就会有 Unknown
回家后我 Review 一下！

[Lumexia]

Sorry, my code seems to have some design issues; it shouldn't be set to UNKNOWN before the first detection, see #30.

[VrianCao]

Sorry, my code seems to have some design issues; it shouldn't be set to UNKNOWN before the first detection, see #30.

I will review it soon.