REST: support ?max-age=<seconds> TTL override on @table resources (not just isCaching)

## Summary

The `?max-age=` query parameter for overriding a record's TTL at write time is not implemented for regular `@table(expiration:)` resources. It only works for `isCaching` resources via the `Cache-Control: max-age` request header.

## Current behavior

PUT/POST to a regular `@table(expiration: N)` resource ignores any `?max-age=` query parameter. The record always expires at the table-level default.

## Desired behavior

A writer can override the TTL on a per-record basis:
```
PUT /ShortLived/item1?max-age=600 → record expires in 600s regardless of table default
```

This is analogous to HTTP cache semantics where the origin can set a per-response TTL.

## Motivation

Found while writing integration tests for fleet-informed test plan (#1191). Production clusters use this pattern:
- Walmart USGM redirect service uses `?max-age=` to set per-redirect expiry at write time (overriding the 1-year table default)

## Implementation notes

The hook point is in `server/REST.ts`: the `isCaching` branch already parses `cache-control: max-age` for caching resources. The `@table` resource path would need to read `req.query['max-age']` and apply it as the record's `expiresAt`.

The existing `expiration` table attribute and `?max-age` header form both ultimately set `expiresAt` on the record — this is about exposing that same mechanism via query parameter for any table type.

## Tracking

Placeholder test exists in `integrationTests/apiTests/ttl.test.ts` (test 3, marked TODO).