fix(ui-web): draw the rail after a re-read replaces its rows

[gloryfromca]

Summary

Restoring a conversation from the archive page put it back everywhere except the
screen. loadSessions replaced the rail's rows and never drew them, and the
restore reaches the rail only through that function, so the row came back in the
server's listing and on disk while the rail kept showing the list from before.
Reloading the page was what appeared to restore it.

Every other writer in this feature already draws after a replace -- leave.ts
does it on both of its transitions, the session registry does it after its
reconcile -- so the fix is the missing call in the one path that did not, rather
than a draw at the restore call site. At boot the rail is still held, where a
draw sets the skeleton and releaseRail paints the rows, so the other caller is
unaffected.

Found while driving the merged archive flow end to end on a real host, after
#585, #589 and #596. It is the same shape as #596: server state correct, screen
stale until a reload.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

On a real host (raven web on an isolated RAVEN_HOME built from a real
config, driven through the browser), reading the archived flag from the last
metadata record of the session transcript rather than from the page:

Step	Before	After
Archive a conversation from the rail	leaves the rail, archived: true on disk	same
Settings, Archive page	it is listed	same
Restart the gateway	still archived, does not come back	same
Restore it from the Archive page	archived: false on disk, rail still does not show it	rail shows it at once
Reload the page	rail shows it	rail shows it

Commands:

• npm test --prefix ui-web -- 189 files, 2470 tests, all pass
• npm run lint --prefix ui-web -- 0 errors (4 pre-existing warnings in
  CronPage/SubagentsPage, untouched here)
• npm run type-check --prefix ui-web -- clean
• npm run --prefix ui-web build && python3 ui-web/build.py -- boot-snapshot OK
  (235 nodes match golden)
• npx commitlint --from github/refactor/ui_web_architecture --to HEAD -- clean

The new case, a plain re-read draws the rows it just replaced, was run against
the unfixed module first and fails there on the assertion it is named for.

• Relevant tests pass locally
• Relevant lint / type checks pass locally
• User-facing docs or screenshots are updated when needed

Risk

One added call in a function with two callers; the other one runs while the rail
is held, where the draw is a no-op beyond the skeleton it already sets. No server
change, no stored state change. Rollback is reverting one commit.

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Related Issues

N/A

[gloryfromca]

No blockers; this can merge as far as I am concerned.

Reviewed the full target diff and the new revision delta. I checked the repository rules and ui-web vocabulary/architecture, both loadSessions callers (boot and archive restore), the parallel registry refresh path, row/store behavior, relevant history, backward compatibility, and that the tests strengthen rather than weaken coverage. The reconciliation preserves client-only running/current state before the newly visible redraw, while boot remains safe because the rail is held until release.

Verification: npm test -- src/features/rail/source.test.ts (14 passed), npm test (2,474 passed across 189 files; Happy DOM emitted aborted localhost fetch diagnostics), npm run type-check (passed), and npx eslint src/features/rail/source.ts src/features/rail/source.test.ts (passed).