Search rejects epoch ms dateStart/dateEnd with 400 INVALID_DATE, although mem-search documents them

## Before submitting - [x] I searched [existing issues](https://github.com/thedotmack/claude-mem/issues) and confirmed this is not a duplicate ### Bug Description `dateStart` and `dateEnd` given as epoch ms always fail with `400 INVALID_DATE` on the search routes and the MCP `search` tool. The mem-search skill documents both as "YYYY-MM-DD or epoch ms" (`plugin/skills/mem-search/SKILL.md:63-64`), so an agent that follows the skill gets an error instead of a filtered search. ### Cause `resolveDateBound` in `src/shared/date-bounds.ts` only treats a JS `number` as an epoch: ```ts if (typeof value === 'number') return requireValidEpoch(value, value, boundary); const normalized = value.trim(); const parsed = isCalendarDatePrefix(normalized) ? new Date(normalized).getTime() : Number.NaN; ``` Over HTTP every query value is a string, and the MCP server forwards params through `URLSearchParams`. So an epoch arrives as `"1762819200000"`, and `new Date("1762819200000")` is `NaN`, which throws. ### Steps to Reproduce ```ts import { resolveDateBound } from './src/shared/date-bounds.ts'; resolveDateBound('2025-11-11', 'start'); // 1762819200000 resolveDateBound(1762819200000, 'start'); // 1762819200000 resolveDateBound('1762819200000', 'start'); // throws 400 INVALID_DATE ``` Or `GET /api/search?query=x&dateStart=1762819200000` returns 400. Before #4786 the same input became `NaN` and quietly matched nothing on the SQLite path, so the documented form has never worked over HTTP or MCP. ### Expected Behavior An all-digit `dateStart`/`dateEnd` is read as epoch ms, the same as a numeric one. A four-digit value like `2025` still reads as a year. ### Environment - **Claude-mem version**: main at 70aa40042 (15.7.0) - **OS**: macOS (the parsing is the same on every OS)