frontend: fix api-error.ts's stale in-transition comment

atlas, on the issue: swarm-controller's problem+json conversion merged
(58588a68, closing hyperhive#3412 which this comment referenced as an
in-flight fix). Every first-party API is RFC 9457 now, so the non-JSON
fallback path is not backend-transition compatibility anymore — it's for
bodies this repo didn't author (a caller pointed elsewhere, or an
nginx-synthesised 502/504 that never reaches our handlers). Comment
updated to say that instead of pointing at a transition that's already
finished.

frontend/packages/shared/src/api-error.ts

@@ -9,12 +9,14 @@
 //
 // RFC 9457 is this hive's committed error-body contract for first-party
 // APIs (mara: "any api of our own responding with error that is not rfc
-// shaped is a bug to be filed against backend") — so the non-JSON
+// shaped is a bug to be filed against backend") — every first-party route
-// fallback below is a *compatibility* path, not a standing requirement.
+// emits it as of this writing, so the non-JSON fallback below is NOT
-// As of this writing it exists for exactly one known gap: swarm-
+// compatibility with an in-flight backend transition (that transition is
-// controller's status route, being converted in a separate in-flight fix.
+// finished). It's for bodies we did not author: a caller can be pointed
-// Once every first-party route emits problem+json, the raw-text path only
+// at something that isn't ours, and an nginx-synthesised 502/504 never
-// ever fires against a genuine bug (worth filing, not silently absorbing).
+// reaches our handlers at all, so it's plain HTML, not problem+json. A
+// first-party route landing here anyway is a bug to file, not something
+// this reader should quietly paper over.
 
 export interface ProblemDetails {
   type?: string;