Documentation clarification — order-lifecycle event completeness & state-as-of guarantees

[wicki2c]

Hello — we are building read-only order/exposure evidence on top of the Hyperliquid info + websocket API
(Python SDK 0.18.0) and want to rely only on documented contract guarantees. Five clarifications, each
about what the API contractually guarantees (not merely what a sample happens to show):

1. State-read and event as-of clocks. Is the top-level time in a clearinghouseState response (and
   l2Book's time) a server-authoritative timestamp for the returned state's as-of instant, or a
   response/send time? For openOrders/frontendOpenOrders, is there any response-level "as-of"
   timestamp for the listing (beyond each order's placement timestamp)? And for order-lifecycle
   events, is an orderUpdates record's statusTimestamp a venue-authoritative event time, or
   receipt/derived?
2. Order-lifecycle event ordering. For the orderUpdates websocket channel, is there a
   client-visible strict ordering token (block height, sequence number, or guaranteed-monotonic value)
   for order-lifecycle events (place/cancel/modify/fill) on a single account/coin — or any equivalent
   documented mechanism by which a client can establish the relative order of those events?
3. Loss detection. Is there any sequence number / cursor / gap marker — or any other documented
   means — by which a client can detect that it missed an orderUpdates message (vs. a silent gap),
   including a frame dropped while the socket remains open?
4. Reconnect replay / backfill for order lifecycle. On websocket reconnect, does the orderUpdates
   "snapshot ack" replay the order-lifecycle events missed during the disconnect (e.g. an intervening
   cancel/modify), or does it deliver only the current open-order state? Is there a REST endpoint to
   backfill order-lifecycle events over a time range (analogous to userFillsByTime for fills), or any
   other documented mechanism to recover order-lifecycle events missed during a disconnect? Does
   historicalOrders expose intermediate lifecycle transitions, or only terminal status?
5. Coverage guarantee through an instant. Taken together — via any documented combination of the
   above or any other supported mechanism — can a client reconstruct a gap-free, ordered,
   loss-detectable lifecycle record for a specific order up to a chosen instant, and is that a
   documented guarantee we may rely on (with its scope/limits), or best-effort?

If any of these are guaranteed, a pointer to the authoritative documentation would be ideal; if any are
best-effort or unsupported, knowing that explicitly is equally useful. Thank you.