Target registry serves the previous runtime's targets after a reinitialize #4009

Description

After a runtime reinitialize changes the generation, useTargetRegistry refetches but keeps serving the destroyed runtime's target list with loading still false until the new response lands. Target pickers therefore present stale targets as selectable during that window, and choosing one fails at send time with a server side target not found instead of being prevented up front.

The sibling useScorerRegistry handles the same transition by gating its returned loading flag on the loaded generation (loading || !ready || loadedGeneration !== generation), and the app already keys server defaults and operation selection by generation the same way. The target registry is the one registry that does not.

Steps to reproduce

1. Open Configuration and reinitialize the runtime.
2. Immediately open Chat or Scanner while the new target list is still loading on a slow backend.

Expected behavior

Target pickers show the loading state for the new generation, like the scorer registry and server defaults already do, instead of offering the previous runtime's targets.