Handlers register `after: 'authentication'` but no handler by that name exists, so the constraint is dropped and every boot warns

## Summary

Several core handlers register with `{ after: 'authentication' }`, but no handler is registered under the name `authentication`, so the chain builder drops every one of those constraints and warns on each boot:

```
[warn]: Middleware ordering: 'rest' requested `after: 'authentication'` but no handler named
'authentication' is registered on port 9926, so the constraint is ignored. Handler names are the
config keys as registered (e.g. 'rest')
[warn]: Middleware ordering: 'mqtt' requested `after: 'authentication'` but no handler named
'authentication' is registered on port 9926, so the constraint is ignored. ...
```

The warning itself is working as designed — it is the registrations that are wrong. Either the name should exist as a registered handler, or these registrations should stop asking for an ordering that cannot be resolved.

## Where

On `origin/main`:

- `server/REST.ts:433` and `server/REST.ts:529`
- `server/mqtt.ts:78`
- `server/graphqlQuerying.ts:701`
- `components/mcp/index.ts:135`

`components/mcp/adapters/harperHttp.ts:6` documents the intent in a comment ("Auth runs upstream via `{ after: 'authentication' }` on the registration"), which suggests the constraint is believed to be doing something.

## Why it looks harmless but is worth fixing

Authentication does still run: it wraps the request path rather than sitting in the port's chain as a peer, so `rest` ends up after authentication by construction. A real request shows the enclosing order `requestHandler → authentication (security/auth.ts) → http (REST.ts)`.

So the practical cost today is boot-time log noise on every port and every restart, plus a misleading breadcrumb: an operator reading `no handler named 'authentication' is registered` reasonably wonders whether authentication is missing from that port, which is alarming and (as far as I can tell) untrue.

The latent cost is that the intended ordering is unenforced. If authentication ever *does* become a named chain entry, or if a handler's position relative to it starts to matter, these constraints will silently continue to do nothing.

I could not confirm the final resolved chain order on the build I was running (5.2.3): `get_status` does not expose `middlewareChains` there, so this is reasoning from the source plus an observed request stack, not from the served order.

## Suggested fix

Either:

1. Register the authentication step under the name these registrations reference, so `after: 'authentication'` resolves and the intent is real; or
2. Remove `after: 'authentication'` from the five registrations and rely on the enclosing auth wrapper, documenting that ordering relative to auth is structural rather than chain-declared.

Whichever way, the warning stops being emitted for a condition no operator can act on.

Start by tracing the middleware registrations in server/REST.ts, server/mqtt.ts, server/graphqlQuerying.ts, and components/mcp/index.ts, then compare them with the authentication wrapper in security/auth.ts and the comment in components/mcp/adapters/harperHttp.ts. Determine whether authentication should be a named chain entry or whether the five ordering constraints should be removed. Done means boots no longer emit these warnings and the intended ordering is documented or enforced.

Written by the indexing model from the issue text.