fix(ep-commerce): say which proxy function is missing, and guard the drift

[field123]

An unknown proxy function 404s with {error: "unknown_fn"}, and readProxyError copies that token straight into Error.message — so a shopper sees unknown_fn and the console logs placeOrder failed {error: "unknown_fn"}. Nothing says the function is absent from the route's dispatch table, which is the one fact needed to act on it.

The 404 body now carries a message naming the function and the reason (readProxyError prefers message, so the client needs no change), a code for callers branching on epProxyErrorCode, and a server-side log line for anyone reading network or server logs.

before: unknown_fn
after:  ep proxy: "placeOrder" is not a registered EP proxy function — the
        proxy dispatch table cannot serve it, so this call only works server-side

A parity test asserts every callEpProxy call site has a FN_DISPATCH entry. applyCartAdjustment and placeOrder sit in a documented allowlist — whether a public proxy route may move money is the open question in #371 — and a companion assertion fails if an allowlisted name becomes dispatchable or stops being called, so the list cannot go stale.

One note: EPCheckoutFormProvider.tsx:455 puts err.message straight into setError, so in the unwired state a shopper now sees the technical sentence rather than unknown_fn. Left deliberately — the designer in the canvas is the only person who can act on it. Branching on epProxyErrorCode(err) === "unknown_fn" for a friendlier string is a possible follow-up.

Fixes #386