feat: record the connection method for session app usage - #31028

Decisions

• D1: nest session_counts by method in place.
• D2: cap over (method, app) pairs; one overflow row per method.
• D3: derive the method at ingest. A protocol method field adds no information while every app name implies its method.
• D4: no reader handles flat rows. Instead, convert the read window and reject flat writes with a CHECK, following the convert-then-constrain pattern of 000417 and the windowed conversion of 000590. Rows older than the window stay flat until purged; nothing reads them. The down migration drops the CHECK and skips them.
• D5: operational readers return arrays of stored objects and coderd sums them. Expanding nested jsonb twice in SQL makes the planner estimate 100 x 100 rows per stat row, which pushes these queries past the JIT thresholds (the deployment reader went from 38 ms to 310 ms, all JIT compile time).

Migration (5M agent stat rows, 968k session app rows, local Postgres)

• Converting workspace_agent_stats: about 43 s. Reads continued, inserts waited, and a flat insert after commit failed on workspace_agent_stats_session_counts_check.
• template_usage_stats_session_apps: the column default fills existing rows without a rewrite, so only reconnecting_pty and port_forwarding rows are updated (about 1.3 s of blocked reads).
• The CHECK is added last, in about 1 ms.

Queries, median ms (main / this PR)

5M rows, 2,000 agents, table clustered by created_at, EXPLAIN (ANALYZE) medians with the window pinned to the newest row:

GetWorkspaceAgentStats and GetWorkspaceAgentStatsAndLabels return jsonb_build_array of the latest row, at no measurable cost.

What keeps these close to main:

• Nested expansion is avoided where it pushed plans past the JIT thresholds. The per-agent and deployment readers aggregate stored objects with jsonb_agg, and GetTemplateInsightsByTemplate expands app names in one call (jsonb_path_query_array(..., '$.*.keyvalue().key')).
• The rollup's stale-row DELETE is bounded by latest_start. Without the bound, the overestimate made it scan the whole child table (573 ms down to 24 ms).
• The overflow row in GetTemplateInsights uses grouped joins instead of per-method subqueries.

The rollup's remaining cost is the extra method level, which needs both keys.

Follow-ups

• Port-forward counting needs a reporter and a UI method label (CLIENT-1053).