No headless path to mint an access grant against a running Orca app

## Summary

An access grant for a running Orca app can only be minted from its own renderer. There is no CLI or RPC path, so pairing a client to an already-running GUI host requires physical access to that host's UI.

## Where minting lives today

1. **Renderer IPC** — `mobile:getRuntimePairingUrl` (`src/main/ipc/mobile.ts`), driven by the *Generate Access Link* button in Settings → Runtime Environments.
2. **`orca serve` startup** — `createPairingOffer` at `src/main/index.ts:1638`.

(2) does not help for a running desktop app: it starts a separate headless runtime with its own runtime id, and pointing it at the same userData means two Electron instances writing one store. The RPC surface has only `pairing.getEndpoints` and `pairing.provisionRelay` (`src/main/runtime/rpc/methods/pairing.ts`) — neither mints a grant.

## Why it matters

`AGENTS.md` calls out the SSH use case explicitly ("All changes must consider the SSH use case. Don't assume local-only execution"), and `docs/reference/headless-linux-server.md` describes hosts with no desktop GUI. Pairing is the one step in that story that still requires a GUI.

Concretely: pairing two machines over Tailscale, both already running Orca. Every other step was scriptable through the CLI; obtaining the grant on the peer was not. The available fallback was driving the peer's Settings UI over `orca computer` through a remote terminal — which then needs Accessibility and Screen Recording granted to the `Orca Computer Use` helper on that machine, so it does not actually remove the physical-access requirement.

## Suggested shape

```
orca pairing create --address [--scope runtime|mobile] [--name ]
```

backed by a new RPC that reaches the same code path as the settings button, returning the pairing URL and web client URL. Address handling should reuse `resolveAdvertisedPairingEndpoint`.

## Security constraint

A grant-minting method **must not** enter `MOBILE_RPC_METHOD_ALLOWLIST` (`src/main/runtime/runtime-rpc.ts:148`). A mobile-scope client minting a runtime-scope grant is a privilege escalation — mobile scope exists precisely to keep `repo.add`/`repo.create`/`repo.clone`/`repo.rm` and friends out of reach. Trusted-local callers only, and revocation should stay visible in the existing grant list so a CLI-minted grant is as revocable as a UI-minted one.

Related: #11083 makes an already-issued offer redirectable, but does not remove the need for GUI access to issue one.

🤖 Generated with [Claude Code](https://claude.com/claude-code)