Editing a ready connection's model reference leaves it ready with absent weights

[JArmandoAnaya]

A local connection at ready stays ready when its model_id or
model_revision is edited, although the weights for the new reference were never
downloaded. setup_state is the row's answer to are the weights here, and the
weights on disk belong to the model the connection no longer points at.

Found during #486 and recorded in that PR's body under "found, not fixed"; this
issue gives it the home the process requires.

cf. #421, #469, #480.

Observed

1. Create a local connection, download its weights — the row is ready.
2. PATCH its model_id to a different curated model.
3. The row is still ready, and nothing on this machine has ever fetched the
   reference it now names.

Why a stale flag is not the whole of it

setup_state is not only displayed. It is what the wire derives
allowed_actions from, and what the read-path family backfill is bounded on, so
the wrong value propagates into answers that look independent of it.

• The declared actions describe a set-up connection. check_integrity is
  offered, and it exists to re-read a snapshot — over a reference whose snapshot
  was never fetched, the honest answer is not a verdict at all.
• The backfill fires on a row it should not. with_families is bounded to
  local + ready + never-asked, and an edited row satisfies all three: feat(inference): connections declare what their model can be asked for #486's
  update correctly forgets model_family, which is what makes it eligible. It
  resolves the new model id against the cache, finds no config, and persists
  "" — somebody looked and it declared nothing. "" is kept distinct from
  None precisely so that a fruitless look is not repeated, so the row now holds
  a finding nobody was in a position to make. A later download repairs it, which
  makes the window quiet rather than harmless.
• A prediction fails at load time instead of being refused up front, because
  the weights are resolved from the cache with local_files_only at the moment
  the provider is built.

The one reader that is already safe is the suggest tool, and only incidentally:
the forgotten family leaves capabilities empty, so #486's filter skips the row.
It is protected by a fact about a different column, not by this one being right.

Fix

A change to the model reference resets the connection's derived knowledge. The
weights on disk belong to the previous reference, so:

• setup_state → not_set_up, for a kind that holds weights of its own.
• the persisted family → None, the nobody has looked value — already the
  behaviour, and it stays.

The existing download action is the visible remedy; no new state and no new
action. Edits that do not touch the model reference — name, device, precision —
change neither, and that is asserted too: resetting on a rename would be its own
bug.

The reset belongs to the kernel service that already validates the edit. The
wire's allowed_actions follow from the state change through the existing
derivation.

Out of scope

• The previous model's cached blobs are not purged. The cache is keyed by
  model and shared, another connection may reference the same one, and editing
  back then costs a cache hit rather than a re-download.
• No UI work beyond what query invalidation already does.
• http connections hold no local weights, so a model-reference edit resets
  nothing weights-related for them.