A version header on every WarpEngine response, and a movable pipeline link

Every WarpEngine API response now carries `WarpEngine-Version`, so a client can branch on
the engine's age without a round trip to ask. Set in a before_action rather than after:
`rescue_from` never reaches an after_action, and a client needs the version most when
something came back wrong. The name lives in `WarpEngine::VERSION_HEADER`. The host's own
endpoints — the store registry — do not carry it, because they are not the engine.

A software has one pipeline, and the newest assignment now wins. Two pipelines pointing at
the same software was not an error the database caught; it was a link that silently did
nothing, with the software still showing whichever row came first. Assigning a software
another pipeline holds therefore moves it, the admin says which pipeline it was taken
from, and `Pipeline#software_taken_from` carries that for anything else that cares.
Deliberately a callback and not a unique index: rows here are soft-deleted, and a unique
index counts deleted rows, so a pipeline removed last year would block its software from
ever being linked again.

The engine is 0.4.0. The site's /stores page and its screenshot follow the client's new
name, and the shot is a fresh one showing the greyed-out titles the client now lists.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -49,6 +49,9 @@ repository's `config.json` and points it at `catalog_url`, and that file remains
 authority on how the store behaves; a repository without a config file is treated
 as no repository at all.
 
+Every WarpEngine API response also carries a `WarpEngine-Version` header — the registry
+above is the host's own endpoint and does not, because it is not part of the engine.
+
 This lives in the host app **on purpose, not in WarpEngine**. The engine serves
 one catalog and has no business knowing which stores exist for it; who ships a
 store for a catalog is a property of the site.