Let bar put place a widget on a bar it does not recognize (#6687)

* Place a bar widget on a bar without the widget it names

'omarchy bar put X --after Y' refused outright when Y was not on the bar, so
migration 1786279107 failed for every user whose clock is their own clone of
omarchy.clock rather than the built-in, and took the rest of the migration
chain down with it. put is the verb a migration or an install reaches for
precisely because it cannot know what the bar it places into looks like, so it
now falls back to the widget's usual spot instead of failing. 'plugin enable',
which someone types, still says when it cannot find the target.

A clone also answers as a placement target now, whether it is the widget the
placement named or the anchor the fallback lands against: cloning the clock
leaves a bar carrying your id where omarchy.clock used to be, and a caller
naming the source means the clone that took its place, the way resolveEnabledId
already routes calls to it. So the widget sits next to that clock rather than
at the end of the section.

Fixes #6678

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

* Keep asking a shell that is still starting

An 'omarchy update' landing while the shell restarts failed migration
1786279107 twice over. Quickshell answers a call made before it finishes
loading with "Not ready to accept queries yet." on stdout and exits 0, so a
caller polling with a ping read a starting shell as up and then took that
sentence for the answer to its real call; report it as unreachable, which every
caller already knows how to handle, and omarchy-restart-shell stops cutting its
readiness loop short on it too.

Reading the plugin manifests is a subprocess behind that, so IPC starts
answering before the registry knows the widget it is being asked to place, and
put refused it as unknown. Say which of the two it is and let put keep asking.

Only a shell that was never there is nothing to fail over. One that never
finishes starting, one that stops responding, one too old to know the call at
all: each has to fail, since omarchy-migrate records a migration that returns 0
as done, and the widget is then never placed and never asked for again.

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

* Fall back for the shell an update has not restarted yet

omarchy-update runs its migrations before omarchy-update-restart, so the shell
answering migration 1786279107 on the update that carries this fix is still the
one that shipped without it, and it refuses the placement exactly as before.
The users this is for would have watched one more update go wrong. put owns the
fallback it documents, so let the command carry it: asked again without the
neighbour the shell says it cannot find, that shell places the widget.

A restarted shell never answers this way — it falls back itself, and knows to
look for a clone of the widget the placement named, which the command cannot.

Having answered once is now remembered across both asks. A shell that speaks
and is then gone has stopped mid-request, and reading that as a machine that
never had one would leave the migration recorded as done.

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

* Wait for a shell that has not appeared yet

A shell being spawned has no socket to answer on, and nothing tells the command
a launch is under way, so a put landing in that window read the silence as a
machine without a shell and carried on — leaving the migration recorded as done
with nothing placed. Give one three seconds to turn up first. A machine that
genuinely has no shell still carries on, three seconds later.

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

* Leave a clone of the widget being put where it is

A clone is the widget it was cloned from wearing its owner's name, so a bar
carrying one already has what put is being asked to place. put only saw the
literal id, and enabling a first-party source whose clone is active is how you
switch back to the built-in — so a migration placing omarchy.keyboard-layout
would have handed a user's own copy back for the shipped one, and called it
done. Targeting learned to read a clone as its source; presence had not.

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

* Trim the comments on the bar put path

Roughly a line of comment per line of code, most of it restating what the code
and the assertion messages already say.

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

---------

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

bin/omarchy-bar

@@ -35,8 +35,9 @@ Placement:
 Enable and disable widgets with 'omarchy plugin enable' and
 'omarchy plugin disable'.
 
-'put' looks for --before / --after within the section it is adding to, and
-falls back to the end of that section when the named widget is not there.
+'put' places a widget the way 'plugin enable' does, but leaves one that is
+already on the bar where it is, and falls back to the widget's usual spot when
+--before / --after names a widget the bar does not carry.
 
 Examples:
   omarchy bar use local.neon-bar
@@ -229,6 +230,38 @@ bar_widget_default_section() {
   ' <<<"$catalog"
 }
 
+# Asks the shell to place a widget, waiting out one still coming up. Answers 0
+# with the reply in PUT_RESULT, 1 when there was no shell to ask. Only an
+# absent shell is carried on from: omarchy-migrate marks a 0 return as done.
+PUT_RESULT=""
+SHELL_ANSWERED=0
+ask_to_put() {
+  local id="$1" placement="$2" attempt absent=0
+  for (( attempt = 0; attempt < ${OMARCHY_SHELL_READY_ATTEMPTS:-50}; attempt++ )); do
+    if PUT_RESULT=$(omarchy-shell shell putBarWidget "$id" "$placement" 2>&1); then
+      SHELL_ANSWERED=1
+      [[ $PUT_RESULT == "not ready" ]] || return 0
+    elif [[ $PUT_RESULT == *"not ready"* ]]; then
+      SHELL_ANSWERED=1
+    elif [[ $PUT_RESULT == *"is not running"* ]]; then
+      # Answered once and now gone: it stopped mid-request.
+      if (( SHELL_ANSWERED )); then
+        fail "omarchy-shell did not become ready; $id was not put on the bar"
+      fi
+      # A shell being spawned has no socket yet, and nothing says a launch is
+      # under way, so give one a few seconds to turn up.
+      if (( ++absent >= ${OMARCHY_SHELL_ABSENT_ATTEMPTS:-30} )); then
+        echo "omarchy-shell is not running; $id was not put on the bar" >&2
+        return 1
+      fi
+    else
+      fail "could not put $id on the bar: $PUT_RESULT"
+    fi
+    sleep 0.1
+  done
+  fail "omarchy-shell did not become ready; $id was not put on the bar"
+}
+
 # Placement lives in the shell, which owns the config it has in memory. Putting
 # a widget therefore asks the shell rather than editing the file behind it.
 cmd_put() {
@@ -250,19 +283,20 @@ cmd_put() {
   [[ -z $PLACEMENT_FROM_SECTION && -z $PLACEMENT_FROM_INDEX ]] ||
     fail "put does not accept --from-section or --from-index"
 
-  # Nothing to place into with no shell to place it, and a caller that runs
-  # unattended should say so and carry on rather than fail. A shell that is
-  # there and refuses is a real error.
-  if ! omarchy-shell shell ping >/dev/null 2>&1; then
-    echo "omarchy-shell is not running; $id was not put on the bar" >&2
-    return 0
+  local placement
+  placement=$(placement_json)
+  ask_to_put "$id" "$placement" || return 0
+
+  # An update runs migrations before it restarts the shell, so this one can
+  # predate the fallback. Ask it again without the neighbour it cannot find.
+  if [[ $PUT_RESULT == "could not find target widget"* ]]; then
+    PLACEMENT_BEFORE=""
+    PLACEMENT_AFTER=""
+    ask_to_put "$id" "$(placement_json)" || return 0
   fi
 
-  local result
-  result=$(omarchy-shell shell putBarWidget "$id" "$(placement_json)") ||
-    fail "could not put $id on the bar"
-  [[ $result != "unknown" ]] || fail "$id is not a known widget; run 'omarchy plugin list'"
-  [[ $result == "ok" ]] || fail "$result"
+  [[ $PUT_RESULT != "unknown" ]] || fail "$id is not a known widget; run 'omarchy plugin list'"
+  [[ $PUT_RESULT == "ok" ]] || fail "$PUT_RESULT"
   # Says nothing about whether it had to be placed: a widget already on the bar
   # is left where it is, and both outcomes are the same answer to the caller.
   echo "$id is on the bar"