Negative TTL accepted at config but bricks the table (opaque 30s handleApplication timeout)

## Summary
A table configured with a negative `expiration` (TTL) installs without error, but throws during lazy per-worker schema-apply → `handleApplication timed out after 30000ms` → every request to that table returns 500; the table is permanently dead (instance survives). The validation guard exists but fires too late.

## Repro
Found via exploratory QA (qa-explorer), harper `001bf7b9c` (v5.1.0, main).
1. Install a component whose schema has `@table(expiration: -1)` (or any negative value).
2. Install succeeds (route registers).
3. First request to the table → 500; logs show `setTTLExpiration` throwing "Expiration can not be negative" during schema-apply, then a 30s `handleApplication` timeout.

## Expected vs actual
A negative `expiration` should be rejected at config/schema-load time (`set_component_file`/install) with a clear validation error — not surface as an opaque 30s timeout and a bricked table.

## Where to look
Guard exists at `resources/Table.ts:932` but runs during lazy per-worker schema-apply rather than at config validation.

## Notes
Related boundary findings: `expiration: 0` is treated as "never expire" (falsy→unset); far-future and sub-second TTLs behave fine. A scratch repro test exists (qa-scratch/ttl-boundary) ready to promote to `integrationTests/database/`.

_Filed from qa-explorer (F-004)._