### System details

Dell XPS 16, Omarchy Quattro Intel Ultra X7 358H Intel Arc B390 

### What's wrong?

* **File:** `/usr/bin/omarchy-tailscale-receive`
* **Line:** 30
* **Function:** `claim_path()`

## 1. The Issue

In the function `claim_path()`, local variables are declared and initialized as follows:

```bash
claim_path() {
  local staged="$1" name="${staged##*/}" base ext candidate index=0
  ...
}
```

In Bash, declaring and assigning multiple local variables within a single `local` statement processes sequentially, but the local bindings are not completely in effect for subsequent assignments in the same command.

Therefore, when the expression `name="${staged##*/}"` is evaluated, the variable `staged` is **not** yet bound to the local variable `staged="$1"`. Instead, Bash evaluates the expression using whichever value of `staged` is currently in the parent/caller's scope, or leaves it empty if no such variable exists.

## 2. Why It Currently Works (and Why It Is Fragile)

Currently, `claim_path()` is called inside `deliver()` as follows:

```bash
deliver() {
  local staged target

  while IFS= read -r staged; do
    target=$(claim_path "$staged") || continue
    ...
  done < <(find "$staging" -mindepth 1 -maxdepth 1)
}
```

Because of Bash's dynamic scoping:
1. `deliver()` declares a local variable named `staged` and assigns it a file path in the `while` loop.
2. `claim_path()` is called.
3. Inside `claim_path()`, the statement `local staged="$1" name="${staged##*/}"` is evaluated.
4. Since `staged` is not yet bound locally during the evaluation of `name`, Bash looks up `staged` in the parent scope.
5. It finds `staged` in `deliver()'s` scope, which has the **exact same value** as `$1` passed to `claim_path()`.
6. Thus, `name` gets assigned the correct value by sheer coincidence of parent variable name collision.

If `claim_path()` is ever called from any other context (e.g., where the caller's variable is not named `staged`, or has a different value), `name` will be incorrectly initialized to empty or to the wrong path.

## 3. Proof of Concept & Reproduction

You can verify this behavior with these simple Bash test cases:

### Test Case 1: Parent scope variable does not exist (Result is empty)
```bash
$ bash -c `f() { local a="foo" b="${a##*/}"; echo "a: $a, b: $b"; }; f`
a: foo, b: 
```

### Test Case 2: Parent scope variable exists (Result resolves to parent value)
```bash
$ bash -c `f() { a="parent"; local a="foo" b="${a##*/}"; echo "a: $a, b: $b"; }; f`
a: foo, b: parent
```

## 4. Proposed Fix

To resolve this scoping dependency and make the function robust and self-contained, split the `local` declaration so that `staged` is bound first:

```bash
claim_path() {
  local staged="$1"
  local name="${staged##*/}" base ext candidate index=0
  ...
}
```