feat: typed error responses with $error<T> and status-keyed response maps

[Copilot]

Adds declared error responses as part of the route contract. Declared HTTP errors resolve as typed tuples on the client instead of rejecting, while unexpected/undeclared failures still reject.

Changes

• $error<T>() marker — new compile-time marker analogous to $type<T>(), distinguishes error branches in a response map
• Status-keyed response maps — response field now accepts { [status]: $type<T>() | $error<T>() } in addition to the existing single-marker form
• ctx.error(status, body) — server handler helper typed to only accept statuses declared with $error<T>(); returns a Response with the given status
• Client tuple resolution — when a route declares $error<T> entries, the client resolves all declared statuses as [error, result, status] discriminated tuples
• Type inference — InferRouteResponse produces the tuple union; InferRouteHandlerResult extracts success types; InferResponseMapErrors types the error helper

Example

const getUser = http.get('users/:id', {
  response: {
    200: $type<User>(),
    401: $error<AuthError>(),
    404: $error<NotFoundError>(),
  },
})

// Server
createRouter().use({ getUser }, {
  async getUser(ctx) {
    if (!authorized) return ctx.error(401, { code: 'UNAUTHORIZED', message: '...' })
    return { id: ctx.path.id, name: 'Ada' }
  },
})

// Client — resolved type is [null, User, 200] | [AuthError, null, 401] | [NotFoundError, null, 404]
const [error, result, status] = await client.getUser({ path: { id: '123' } })

Backward compatibility

Existing response: $type<T>() and response: ndjson.$type<T>() routes are unchanged — no tuple wrapping, no breaking type changes. The response map form is purely additive.