Flicker on resize/fullscreen: stale com.koekeishiya.yabai agent runs alongside com.asmvik.yabai after fork migration

## Summary

After updating to this fork, I ended up with **two yabai master processes running simultaneously**, which caused intermittent window **flicker** on resize and on zoom-fullscreen. The root cause is that this fork renamed the launchd service from `com.koekeishiya.yabai` to `com.asmvik.yabai`, but the old service was left enabled and installed on the system — so both the old and new agents ran at once and fought over window events.

I suspect this can happen to **anyone migrating to this fork from upstream yabai** (or from an earlier build that used the old label).

## Symptoms

- Windows visibly **flicker** when resizing a tiled window or toggling zoom-fullscreen.
- The flicker is **intermittent**, not constant — it's a race, so it doesn't reproduce every time.
- Separately (and continuously, not per-action), the `stderr` log steadily accumulates thousands of:
```
yabai: could not acquire lock-file! abort..
```
one line each time the losing instance is relaunched by launchd and fails to acquire the lock. In my case this was ~6840 lines built up over ~3 days. Note the flicker and this lock-file loop are two separate symptoms of the same cause (two instances) — they run on different clocks; a flicker does not emit a lock-file line.
- The launchd job shows a very high restart count and `last exit code = 78: EX_CONFIG`.

## Root cause

Two independent yabai instances were alive at the same time:

| Service label | Origin |
|--------------------------|---------------------------------|
| `com.asmvik.yabai` | this fork (current) |
| `com.koekeishiya.yabai` | old/upstream service, still enabled |

Both were:
- launched from the same binary,
- bound to the same socket (`/tmp/yabai_$USER.socket`),
- subscribed to the same CoreGraphics window events.

On every resize / fullscreen, **each instance independently re-applied its own layout**, racing the other — that's the flicker. Because the two instances ended up holding **different lock-file inodes**, yabai's single-instance lock guard never actually blocked the second instance; instead the loser just logged `could not acquire lock-file! abort..`, exited, and was relaunched by launchd in a loop (hence the huge restart count and `EX_CONFIG`).

The reason both existed: the service label was renamed (`com.koekeishiya.yabai` → `com.asmvik.yabai`), but nothing removed/disabled the previously-installed agent under the old label. `yabai --start-service` / `--restart-service` only manage the new label, so the stale old agent kept running invisibly.

## How to detect

```sh
# More than one master process?
pgrep -fl '/yabai$'

# Both service labels present?
launchctl list | grep -i yabai
ls ~/Library/LaunchAgents/ | grep -i yabai # com.koekeishiya.yabai.plist AND com.asmvik.yabai.plist

# Repeated lock-file errors + restarts?
grep -c 'could not acquire lock-file' /tmp/yabai_$USER.err.log
```

## Fix (manual)

Disable and remove the stale old-label agent, keep only the fork's:

```sh
launchctl bootout gui/$(id -u)/com.koekeishiya.yabai
launchctl disable gui/$(id -u)/com.koekeishiya.yabai
rm ~/Library/LaunchAgents/com.koekeishiya.yabai.plist
# then start the fork's service cleanly
yabai --restart-service
```

After this there is a single master, the lock-file errors stop, and the flicker is gone.

## Suggested improvements

1. **Migration handling:** on `--install-service` / `--start-service`, detect a previously-installed agent under the old `com.koekeishiya.yabai` label and bootout/disable/remove it (or at least warn loudly).
2. **Harden the single-instance guard** so a second instance that can't acquire the lock cannot end up bound to the socket and processing events — the current behavior degrades to a relaunch loop rather than a hard "another instance is already running" refusal.
3. **Document the rename** in the README/migration notes so users coming from upstream know to remove the old service.

## Environment

- yabai: v7.1.25 (this fork)
- macOS: 26.5.1 (build 25F80), Apple Silicon
- SIP: partially disabled (scripting addition loaded)

Start with the --install-service, --start-service, and --restart-service entry points and trace how the com.asmvik.yabai launchd agent is installed and managed. Read the README or migration notes for the service-label transition. Done should prevent or clearly report a stale com.koekeishiya.yabai agent, ensure only one master remains, and document migration cleanup.

Written by the indexing model from the issue text.