Record prod DDL and start-phase numbers after #501 deploys

[FlyM1ss]

Follow-up to #501 (Track A of the backtest speed-and-trust design). The plan's
Final verification tables have their local columns filled and their prod
columns deliberately blank, because prod is the only place Neon DDL and
connection setup exist at all — locally every store resolves to its SQLite twin,
which nothing in that PR guards, so a local before/after of ATL_BACKTEST_WORKER
measures exactly zero.

Two readings, both from the deploy that ships #501.

1. Pre-change baseline — the parent's own boot. Open the Render deploy log for
srv-d7lbmpjbc2fs73bcr6t0 and grep 'backend: schema init'. The parent is never a
worker, so it runs every store's DDL against the same Neon databases the child used
to: eleven timed lines, six of which name the twins a child constructs. Those six are
the round trips the child no longer pays. Note which line is preceded by
🏊 pg pool created for … — that store's figure carries the cold handshake for its
URL and the later stores on the same URL do not.

2. After — the child. Launch one onboarding backtest and grep the same log for the
child's schema init skipped (backtest worker) lines and its ⏱ phase /
spawn+interpreter … lines. Expect six skip lines (the six twins its import graph
builds, not eleven) and schema DDL 0.00s in the starting split.

⚠ Do not race a live poll for the phases: /backtest/status exposes phases[]
only while the run is in flight, and the parent unlinks the progress file the moment
it ends (backtests.py:1993). The child prints every transition to stdout and the
parent dumps that into the service log under === BACKTEST SCRIPT OUTPUT ===
(backtests.py:1773), head+tail bounded at 32k each — these lines are at the head, so
truncation cannot eat them.

How to read the result: the child's zero is a check, not a saving — it says the
flag fired. The saving is the parent-boot column. Five skips plus a sixth timed line
means the flag failed to reach one twin, which is exactly the case the timed direction
exists to make visible.

Local numbers already recorded, for comparison: the import probe counts 107
statements over 6 _init_schema calls before vs 0/0 after; and the dark window
is ~21s of which ~86% is loading_bars, not schema — so do not expect this to be
large in wall-clock terms. The point is to confirm the flag fires in production and to
put a real number on what the parent pays.

Fill both tables in docs/superpowers/plans/2026-09-20-backtest-visible-start.md and
commit on a fresh branch — never on feat/backtest-visible-start after #501 merges
(commits behind a merged PR orphan silently).

[FlyM1ss]

Part 1 — the parent's own boot: done

Read from the #506 deploy log (srv-d7lbmpjbc2fs73bcr6t0, 2026-09-22 20:13). Eleven timed lines, exactly as the guard's timed direction predicts.

store	schema init	notes
run history	4.78 s	🏊 run-history pool created 4.7 s earlier — carries that pool's cold handshake
agent_store	1.34 s	🏊 content/users pool created 1.3 s earlier — carries that pool's cold handshake
model_provider_store	1.33 s
analytics_store	1.16 s
user_store	1.10 s
portfolio_store	0.42 s
credits_store	0.39 s
agent_version_store	0.29 s
broker_connections	0.23 s
agent_credential_store	0.23 s
strategy_store	0.23 s
total	11.50 s

Bold = one of the six twins a backtest child constructs. They sum to 9.23 s.

How much of that is actually saved

Not all 9.23 s. Two of the six are the first store to touch their pool, so their figure includes a cold Neon handshake the child pays regardless:

• certain floor: 3.11 s — the four on already-warm pools (model_provider_store 1.33 + analytics_store 1.16 + credits_store 0.39 + broker_connections 0.23). Pure DDL round trips, removed outright.
• ceiling: 9.23 s — if the two handshake-carrying lines were nearly all DDL.

The true figure sits between, and this log cannot split it: the handshake and the DDL are inside one timed interval. PostgresBacktestDatabase alone is 55 of the child's 107 statements, so run history's share is probably substantial — but that is an inference, not a measurement, and it is not in the table.

So: ≥3.11 s per dashboard backtest launch, ≤9.23 s. As the issue predicted, small against a ~21 s dark window that is ~86% loading_bars.

Part 2 — the child: still pending

Not blocked, just waiting on a completed prod run. The child's schema init skipped (backtest worker) lines and its ⏱ phase / spawn+interpreter split are child stdout, and the parent only dumps them into the service log under === BACKTEST SCRIPT OUTPUT === when the run ends.

A run launched at 20:21:22 (⏱️ Subprocess timeout: 3600s) was still in flight as of 21:09, so none of those strings is in the log yet. Checked three times over 90 minutes; no dashboard backtest has completed in prod in the last 8 hours.

Nothing to change — the next completed run produces it. Expect six skip lines and schema DDL 0.00s in the starting split.

Incidental, and much larger than anything here

While reading this boot I measured the startup hook: 99.5 s, and all of it is one call — credits_service.backfill_default_signup_credits, which walks all 241 users serially and grants zero. That is ~10× everything Track A removed, on every deploy, and it grows linearly with signups. Filed separately as #518.

Also: the deploy-log endpoint IDs are real Neon endpoints, so they are deliberately not reproduced above.