bregctl dev stop: refuses while a failed start is still exiting instead of waiting

## Use Case

A wrapper (a launcher, a test harness) runs `bregctl dev start` and, when anything fails, runs `bregctl dev stop` in its cleanup path.

## What we hit

When `bregctl dev start` fails shortly after BREG came up, the cleanup `bregctl dev stop` issued immediately afterwards refuses:

```text
another local lifecycle operation or supervisor is active
```

with `dev.failed` and `suggestedAction: correct_command_usage`. The supervisor is still exiting. Nothing tells the caller to retry, and a wrapper that records the last error loses the original start failure to this one.

`completed_supervisor_lock` in `crates/registry-bregctl/src/dev/mod.rs` waits up to 5 s for the supervisor lock only when the recorded status is `Stopped` or `Stopping`. For any other status (here the session was not yet recorded as stopping) the deadline is zero, so the first contended lock attempt is final.

## Proposed Behavior

- `dev stop` waits a bounded time for an exiting supervisor regardless of the recorded status, as the stopped-state path already does.
- When it still cannot take the lock, the refusal says a supervisor is still running, whether it is exiting, and that retrying is the expected action (not `correct_command_usage`).

## Boundaries

- Never stop or take over a supervisor that belongs to a live session.
- No unbounded wait.

Start in crates/registry-bregctl/src/dev/mod.rs, focusing on completed_supervisor_lock and the dev stop lifecycle path. Run the existing dev start/stop failure scenario to observe the lock contention. Done means stop waits for a bounded period regardless of the recorded status, preserves live-session safety, and reports retrying when an exiting supervisor still holds the lock.

Written by the indexing model from the issue text.