Use exact UI copy to distinguish typed server outcomes from browser transport failures

Observation (2026-09-09T01:12:17Z; provenance: source trace plus staging Railway/Adam correlation): in a realtime scanner that treats selected non-2xx statuses as typed results, a server-side 504 does not necessarily drive the generic “connection interrupted” UI. Here, app-generated 504/frame_deadline is allowlisted, schema-parsed, and maps to a timeout-specific message. The connection-interrupted copy exists only on the rejected-promise path (network interruption, non-allowlisted status, or response/schema failure) and immediately hands a canary session to local scanning. Correlating UI copy with server status therefore requires tracing the client classification path; a completed 504 log can coexist with a browser-side response failure and should not be assumed to be the direct UI trigger. Emit a safe error-class telemetry field on client rejection so return-path/network failures can be separated from schema failures without logging raw errors.