feat: use HTTP POST for bootstrap to avoid WSS TLS handshake

[akiasprin]

Bootstrap JSON-RPC over HTTP POST

Bootstrap now uses HTTP POST for JSON-RPC calls instead of WebSocket. This allows the initial data load to reuse the page's existing HTTPS connection and removes WebSocket connection establishment from the bootstrap critical path.

Why

Bootstrap is latency-sensitive because no node data can be displayed until the initial RPC requests complete.

Previously, bootstrap requests were sent over WSS. Although a WebSocket handshake starts as an HTTP Upgrade request, browsers do not reuse the fetch/XHR connection pool for WebSockets — new WebSocket() always establishes a separate connection (RFC 6455 §4.1). Even on the same origin, this requires an additional TCP/TLS handshake before any RPC request can be sent.

In practice, establishing a WSS connection can easily take around 100–200 ms depending on network conditions. Only after the handshake completes can the first JSON-RPC request be sent, and the response typically requires another network round trip (~50–100 ms).

As a result, bootstrap could spend roughly 200–300 ms waiting on connection setup and the first response before any data becomes available.

By moving bootstrap RPCs to HTTP POST, requests can be issued immediately over the page's existing HTTPS connection. The WSS connection is still established in the background and remains available for subsequent polling and updates.

Before

Bootstrap loaded data through WSS:

Create WebSocket
    ↓
TCP/TLS Handshake
    ↓
JSON-RPC Request
    ↓
JSON-RPC Response

The initial data fetch was blocked on WebSocket connection establishment.

After

Bootstrap loads data through three parallel HTTP POST JSON-RPC calls:

HTTP POST (listAgentUuids)
HTTP POST (meta/static)
HTTP POST (dynamic)

These requests reuse the existing HTTPS connection and can start immediately. Meanwhile, the WSS connection is established asynchronously in the background for subsequent polling.

Changes

File	Change
src/api/client.ts	Exposed url, token, and name as public readonly; added httpRpcCall(), which converts wss:// URLs to https:// and sends JSON-RPC requests via HTTP POST
src/hooks/useNodes.ts	Switched bootstrap to httpRpcCall(); loads listAgentUuids, metadata/static data, and dynamic data in parallel; removed the separate tickDynamic() bootstrap call

---

Bootstrap 阶段改用 HTTP POST 发送 JSON-RPC

Bootstrap 阶段改为通过 HTTP POST 发送 JSON-RPC 请求，而不再依赖 WebSocket。这样可以直接复用页面已有的 HTTPS 连接，并将 WebSocket 建连过程移出 Bootstrap 的关键路径。

为什么

Bootstrap 对延迟非常敏感，因为在初始 RPC 请求完成之前，页面无法展示任何节点数据。

此前 Bootstrap 通过 WSS 发起请求。虽然 WebSocket 握手本质上是一个 HTTP Upgrade 请求，但浏览器不会让 WebSocket 复用 fetch/XHR 的连接池——new WebSocket() 总是建立独立连接（RFC 6455 §4.1）。即使是同源请求，也需要额外完成一次 TCP/TLS 握手后才能发送 RPC 请求。

实际网络环境下，建立 WSS 连接通常需要约 100–200 ms。只有握手完成后才能发送第一个 JSON-RPC 请求，而等待请求返回通常还需要额外一次网络往返（约 50–100 ms）。

因此在节点数据可用之前，Bootstrap 很容易额外消耗约 200–300 ms 的等待时间，仅仅用于连接建立和首个请求返回。

改为 HTTP POST 后，Bootstrap 请求可以立即通过页面已有的 HTTPS 连接发出。同时 WSS 连接仍会在后台建立，并继续用于后续轮询和实时更新。

改动前

Bootstrap 通过 WSS 加载数据：

Create WebSocket
    ↓
TCP/TLS Handshake
    ↓
JSON-RPC Request
    ↓
JSON-RPC Response

初始数据获取必须等待 WebSocket 建连完成。

改动后

Bootstrap 改为通过三个并行 HTTP POST JSON-RPC 请求加载数据：

HTTP POST (listAgentUuids)
HTTP POST (meta/static)
HTTP POST (dynamic)

这些请求直接复用现有 HTTPS 连接，可立即开始执行；与此同时，WSS 连接在后台异步建立，供后续轮询使用。

代码改动

文件	改动
src/api/client.ts	将 url、token、name 暴露为 public readonly；新增 httpRpcCall()，将 wss:// 转换为 https:// 并通过 HTTP POST 发送 JSON-RPC 请求
src/hooks/useNodes.ts	Bootstrap 改为使用 httpRpcCall()；并行加载 listAgentUuids、meta/static 和 dynamic 数据；移除单独的 tickDynamic() 初始化调用