Date @primaryKey is unusable — every insert 500s 'Unable to serialize object as a key'

## Summary

A `Date` attribute declared as the primary key installs fine, but **every insert 500s** with `Unable to serialize object as a key`. The table can be created but never written to.

## Severity

Low–medium — fail-stop (no data loss/corruption), and there's a workaround (use a `Long` epoch-ms PK, which sorts chronologically and is writable). But a natural modeling choice (timestamp/Date as PK for time-series/event tables) is silently broken at write time with an opaque 500.

## Repro

Schema:
```graphql
type Stamped @table @export {
when: Date @primaryKey
v: Int
}
```
Then any insert (REST PUT / ops `insert`) → `500 Unable to serialize object as a key`.

## Root cause

`coerceType` (`resources/Table.ts`) returns a JS `Date` **object** for a Date-typed attribute; the ordered-binary key path (`checkValidId` → `writeKey`) has no `Date` case and throws on the object.

## Recommendation

Either add a `Date` case to the ordered-binary `writeKey` (serialize as the epoch-ms numeric key so it sorts chronologically), or reject a `Date @primaryKey` at schema-load with a clear validation error rather than a per-insert 500.

(Adjacent temporal note — D-055, doc: timezone-less `Date` *attribute* strings are parsed as server-local time via `new Date(value)` with no `Z`-append, while the PK path forces UTC — asymmetric and server-`TZ`-sensitive. Worth documenting that date values should carry a timezone or use epoch-ms.)

---
*Surfaced by the QA-explorer campaign against Harper `7aaa5a152`; the key-serialization path is not changed vs `main` @`6797f091d` (the only feature-branch delta is an unrelated revalidation line). Filed by Claude (Opus 4.8) for @kris.*

Start in resources/Table.ts at coerceType, then trace the checkValidId to writeKey path described in the issue. Reproduce the Date primary-key insert with the shown schema and REST PUT or ops insert; done means Date keys are writable with chronological epoch-ms serialization, or schema loading rejects them with a clear validation error.

Written by the indexing model from the issue text.