os: 1bit-update refuses the second update on the machine's own save layer (#1334 follow-up) #1376

os/v3/puppy/embed/usr/local/bin/1bit-update (merged in #1334) lets an installed machine take one in-place update. The second is refused on the machine's own save layer.

Mechanism (main f559162):

• save_slot is computed as the slot holding the real <prefix>save directory (:96-106). The update only ever links the layer into the other slot (:249), so save_slot stays 1bit permanently.
• After update 1 the machine runs psubdir=1bit-alt, so update 2's target is 1bit (:80).
• The target guard (:235-243) then finds /1bit/upup64rsave, which is this machine's shared layer, as a real directory and dies with /1bit already holds a save layer (upup64rsave): two layers cannot be merged by an update.
• update-gate.sh never runs a second update (its boots are update → boot alt → rollback → boot original), so its green does not cover this.

Reproduced without a VM: a fake /data (with 1bit/upup64rsave a real dir, 1bit-alt/upup64rsave -> ../1bit/upup64rsave), running the script's lines 79-83, 96-106 and 235-243 with active=1bit-alt:

active=1bit-alt target=1bit save_slot=1bit savename=upup64rsave
DIE(rc 2): /1bit already holds a save layer (upup64rsave): two layers cannot be merged by an update - pick the slot by hand if that is really what you want

A second latent defect on the same path: skipping the guard alone would run ln -sfn ../1bit/upup64rsave /data/1bit/upup64rsave against the real directory, creating a self-referencing upup64rsave/upup64rsave inside the layer. And the layer scan is "last real directory wins", so with a second, foreign layer in the other slot it would pick that one.

Found in review of #1334 (CHANGES at a0cc2d50/81ae64ee; it merged at 16:10Z on a READY at an older head). Part of #712 item 2.