The deferred cleanup in `doBackFill` ran its `UPDATE readview_status SET
filler = ''` on the same parent context as the rest of the backfill.
When the backfill was aborted by ctx cancellation (deploy shutdown,
caller timeout, etc.) the cleanup also fired on the cancelled ctx and
silently failed with "context canceled". The status row stayed marked
"filling" until the heartbeat window expired, blocking takeover by
other instances for that whole heartbeat period.

Same issue affected the BeginTx-error path which used the parent ctx
to run its own cleanup UPDATE.

Both paths now route through `resetBackFillStatus`, which:
- uses a fresh `context.Background()` derived ctx with a short
  timeout (mirroring the final-commit pattern at the bottom of the
  loop body),
- acquires a dedicated `*sql.Conn` from the pool so the underlying
  connection used by the just-cancelled transaction can't interfere
  while the driver is still tidying it up,
- returns the error so the caller decides whether to log or surface
  it.

The existing `cancel context` test asserts the cleanup is attempted
on the new path; sqlmock cannot fully simulate Go's database/sql
auto-rollback behaviour after ctx cancellation (the underlying conn
is left in a state neither ExecContext nor Conn can acquire), so the
log assertion accepts the sqlmock-specific error string. Production
behaviour against a real Postgres pool releases the conn correctly
and the cleanup succeeds.

`Reset` ran the resetHandler under a FOR UPDATE NOWAIT lock, then DELETEd
the readview_status row and committed (releasing the lock) before
calling `initiateBackFill`. Between commit and the first INSERT inside
`doBackFill`, the status row was missing. A concurrent `Start` on
another instance reaching its messageHandler / startFn in that window
saw `sql.ErrNoRows` from the SELECT, defaulted `currentSeqNo` to 0,
treated `backFillInProgress(nil, nil)` as false, and entered the
`currentSeqNo == 0` branch — which calls the same resetHandler again.
Two resetHandlers could then race against the same read model.

Instead of DELETE + later re-INSERT, atomically reset the row in place
to (current_seq_no=0, filler=hostname, started=now). The row never
disappears; from this point onward other instances see
backFillInProgress=true and back off until our doBackFill clears the
filler. The lock window doesn't extend across the rebuild — it doesn't
need to — but the state visible to other instances is now
"a backfill is in progress" rather than "nothing exists".

Updated TestReadview_Reset subtests to expect the new INSERT-on-conflict
statement instead of DELETE, and shifted the doBackFill final-commit
timestamps in two subtests by one `r.now()` tick to account for the
fresh INSERT consuming one now-call.

fix(readview): run backfill cleanup on a fresh ctx + dedicated connection

See merge request !275

fix(readview): keep status row present during Reset so concurrent Start cannot race

See merge request !276

chore(release): prepare for v0.6.11

See merge request !277