[Core] No per-component hook to shape auth error responses (OpenAI-compatible endpoints can't return their own 401 envelope)

Surfaced by @kriszyp reviewing #1616 (the `/v1` OpenAI-compatible gateway, #631).

## Problem

Authentication runs ahead of the REST chain — correct ordering — but it means invalid or expired credentials are short-circuited by `security/auth.ts` before any `/v1` Resource executes. That path serializes `{ error: err.message }`, whereas an OpenAI-compatible endpoint must return:

```json
{ "error": { "message": "...", "type": "...", "code": null, "param": null } }
```

So the gateway can shape every error it actually reaches (`toOpenAIError`), but not the single most common SDK failure path: a bad `Authorization: Bearer` token. An unmodified OpenAI/LangChain client hitting an expired token gets a body it can't parse as an API error.

Note this is a general gap, not an OpenAI-specific one: any component exposing a foreign wire protocol over Harper's HTTP surface has the same problem — it owns its error envelope right up until auth rejects the request.

## Ask

A supported way for a component to normalize auth-rejection responses for the paths it owns (e.g. a `/v1`-scoped wrapper/hook), **without** weakening the auth-before-REST ordering. The gateway should not have to patch shared auth to get a correct 401.

Should also come with an end-to-end invalid-Bearer assertion — the current integration test mints a valid token and never exercises this path.

Context: #631 (Phase 4 of #510), #1616. Companion to #1931.

🤖 Filed with [Claude Code](https://claude.com/claude-code) on behalf of @heskew

Start with security/auth.ts and inspect the /v1 gateway's existing error shaping, including toOpenAIError. Find the current integration test that covers valid tokens and add an invalid-Bearer case. Done means a component-scoped mechanism preserves auth-before-REST ordering while returning the component's 401 envelope.

Written by the indexing model from the issue text.