store: Persist postponed index creation as a once-only operation

Track postponed-index creation in a new `postponed_indexes_created`
column on `subgraphs.deployment` so the decision survives restarts and
external index cleanup. The runner already gates creation on proximity
to chain head; this makes the gate persistent.

Two problems with the prior behavior are fixed:

1. An external process removes unused indexes. Because every call used
   `CREATE INDEX CONCURRENTLY IF NOT EXISTS` and we re-entered
   `create_postponed_indexes` on every restart, manually-dropped
   indexes were recreated. The flag now short-circuits the call after
   the first successful creation.

2. `start_subgraph` called `create_postponed_indexes` eagerly on every
   restart, including immediately after a graft when the deployment is
   far below chain head. That call is removed; the runner-side path
   (already gated by `close_to_chain_head`) is now the only trigger.

The migration sets the flag to TRUE for deployments where
`synced_at IS NOT NULL`, since those already had their postponed
indexes created under the old code path.

Also removes the redundant `WritableStore::postponed_indexes_created`
AtomicBool: the runner's in-memory guard already limits calls to at
most one per restart, and the DB is now the single source of truth.