boot: reconcile fast-forward does not re-open the store snapshot, so in-memory state is built from the pre-reconcile tree

## What

`buildApp` registers the plugins in this order: `store` (opens the gitsheets public store; each Sheet caches a `dataTree` snapshot at open time) → `reconcile` (fetch + fast-forward/rebase against `origin/`) → `services` (builds `InMemoryState` + FTS from `fastify.store.public`).

When the local bare clone is behind origin at boot, `reconcile` fast-forwards the branch, but nothing calls `Store.swapPublic` afterwards. `services` then builds the in-memory state from the Sheet snapshots captured before the fast-forward. Records that arrived in the fast-forward are invisible until the next hot-reload webhook or a restart.

The hot-reload path (`reloadInMemoryStateAndFts`) already handles this correctly by re-opening the public store after reconcile. The boot path skips that step.

## Why it hasn't bitten

Production pods bare-clone the data repo on every boot (`emptyDir` volume), so the clone is in sync with origin by the time `reconcile` runs and the outcome is `in-sync`. The gap only shows when a clone is reused across boots: local dev, and tests that seed the remote after creating the rig (see the re-import test in `apps/api/tests/internal-reload.test.ts`, which works around it with an explicit `git fetch origin main:main` before boot).

## Fix sketch

In the `reconcile` plugin (or a small step between it and `services`), when the outcome is anything other than `in-sync`/`fetch-failed`, re-open the public store and `fastify.store.swapPublic(freshPublic)` before `services` reads it. Or reorder so the store opens after reconcile; `reconcile` only needs the repo path and the lock, not the Sheet handles.

Found while working on the hot-reload stale-indices fix (`fix/hot-reload-stale-indices`); out of scope there.