Stop re-creating a controlling-PC link that was already there

Reported: moving machine 3016 on the map and saving answered "this
relationship already exists" and refused the save.

The map had nothing to do with it. Every save of the machine form re-POSTed the
controlling-PC link, and the server was right to refuse it - the row was already
active, and assetrelationships is unique on (source, target, type). Any edit to
a machine that has a controlling PC hit this; a position change is just the one
somebody happened to be making.

The form asked the wrong question. It used "do I know the existing link's id" as
a stand-in for "is there an existing link", and read that id from
rel.assetrelationshipid - a key the API has never emitted. to_dict serialises
column names and the column is relationshipid, so the read was undefined on
every load while controllingPcId was populated from the same relationship. The
two answers disagreed, and the disagreement was invisible: undefined is not an
error, it is just a falsy id.

That single conflation caused both failures. Saving anything re-created the
link, and CLEARING the controlling PC did nothing at all, because "no selection
and no known id" reads as "nothing to do" - so removing a machine's controlling
PC silently kept it. Only the first of those was reported, and the second is the
one somebody would have trusted.

Fixed by making the LOADED PC the authority on whether a link exists, with the
relationship id used only to delete a row. If that id ever goes missing again
the worst case is a link that cannot be removed, never a duplicate create.

The decision moved to controllingPc.js as a pure function so it could be pinned
by tests, following labelPages.js. Unchanged is now explicitly no-op rather than
delete-then-create: re-linking a machine to the same PC opens a window where it
has no controlling PC at all, and resolve_asset_position walks that edge, so a
failure between the two calls would drop the machine's inherited position along
with its link. The specs also cover a select handing back '42' against an API
that gave 42, which would make an untouched link look like a swap and reach the
same duplicate POST by another route.

Not the printer assignment, which was the first guess: PrinterAssignmentPicker
makes no relationship calls, and its save is wrapped in a catch that only logs,
so it cannot surface an error from this form at all.

CHANGELOG.md

@@ -105,6 +105,16 @@ ADR-007 and ADR-002.
   the wrong code. The page index now travels with the page.
 - The back label's dotted preview outline outspecified the print reset and drew
   a dashed rule down the edge of every second card.
+- **Saving a machine that has a controlling PC answered "this relationship
+  already exists" and refused the save.** Reported against a map position
+  change, but the map was incidental: the form re-POSTed the controlling-PC
+  link on every save, and the row was already there. It used "do I know the
+  existing link's id" as a stand-in for "is there an existing link", and read
+  that id from a key the API does not emit, so the two disagreed on any machine
+  that had a PC. The same conflation meant CLEARING a machine's controlling PC
+  silently did nothing, which was the more dangerous half and had not been
+  reported. The loaded PC is now what decides, and re-selecting the same PC is
+  a no-op rather than a delete-and-recreate.
 
 ### Changed