bug: /logs `start` query parameter is silently ignored

[whoabuddy]

Summary

The start query parameter on GET /logs is silently ignored. The endpoint returns the most-recent limit records regardless of the requested timestamp window, which breaks any time-windowed triage or baseline comparison.

Reproduction

Query with a recent start timestamp:

curl -s -H "X-Admin-Key: $ADMIN_API_KEY" -H "X-App-ID: x402-relay" \
  "https://logs.aibtc.com/logs?limit=2000&level=WARN&start=2026-04-16T17:52:00.000Z"

Expected: records with timestamp >= 2026-04-16T17:52:00.000Z.

Actual (observed 2026-04-16 ~18:15 UTC):

{
  "requested_start": "2026-04-16T17:52:00.000Z",
  "oldest_returned": "2026-04-13T13:06:54.627Z",
  "newest_returned": "2026-04-16T18:19:22.218Z",
  "total": 2000,
  "records_before_start": 1982
}

1,982 of the 2,000 returned records are older than the requested start. The cap of 2,000 and ordering-by-newest is intact; the start filter is just not applied.

Impact

• Breaks every /log-triage pre/post-merge baseline workflow
• Forces callers to client-filter large result sets, defeating the purpose of the query filter
• Silent failure — no error returned, so callers assume their window is honored

Expected behavior

When start is provided, the SQL query should include WHERE timestamp >= ? (and similarly for end if that parameter exists). Return only records within the window, up to limit.

Suggested fix locations

• src/index.ts — GET /logs handler, where query params are parsed
• src/durable-objects/app-logs-do.ts — the SQLite query that backs /logs

Verify the param name matches what the handler reads (e.g., start vs since vs from) and confirm the DO SQL builder includes it.

Priority

Medium — no user-facing production impact, but it silently corrupts any log-based triage, baselining, or incident investigation. Affects all downstream tooling including /log-triage skill.