Persona edits silently leave linked instance parallelism and ACP command stale

## Summary

In `desktop-v0.5.8`, editing a persona does not propagate `parallelism` or `acp_command` to already-linked instances, while neighboring persona-backed fields do update. The UI gives no indication that the persisted instance has diverged from the values shown in the persona dialog.

This is a consistency bug rather than a feature request: these two fields bypass the effective-config/live-persona paths used by adjacent settings, and the mismatch is silent.

## Evidence

For a linked record, [`resolve_effective_config`](https://github.com/block/buzz/blob/desktop-v0.5.8/desktop/src-tauri/src/managed_agents/effective_config/mod.rs#L247-L260) matches `record.persona_id`; [`resolve_linked`](https://github.com/block/buzz/blob/desktop-v0.5.8/desktop/src-tauri/src/managed_agents/effective_config/mod.rs#L74-L109) then resolves model, provider, and system prompt from the persona. Those fields therefore reflect persona edits.

Persona environment variables are also live at spawn: the descriptor is documented and applied as `definition ... -> global -> live persona -> per-agent` on every spawn ([`runtime.rs:801-810`](https://github.com/block/buzz/blob/desktop-v0.5.8/desktop/src-tauri/src/managed_agents/runtime.rs#L801-L810)). I also confirmed this at runtime by adding a variable only to the persona definition and observing the child process read it.

`parallelism` and `acp_command` bypass those paths:

- [`runtime.rs:677-678`](https://github.com/block/buzz/blob/desktop-v0.5.8/desktop/src-tauri/src/managed_agents/runtime.rs#L677-L678) computes `BUZZ_ACP_AGENTS` from raw `record.parallelism`.
- [`runtime.rs:476-477`](https://github.com/block/buzz/blob/desktop-v0.5.8/desktop/src-tauri/src/managed_agents/runtime.rs#L476-L477) resolves raw `record.acp_command`.

The persona update path does not refresh either snapshot. Its helper explicitly propagates only a `display_name` rename ([`personas/update.rs:31-35`](https://github.com/block/buzz/blob/desktop-v0.5.8/desktop/src-tauri/src/commands/personas/update.rs#L31-L35)), and the update path only considers avatar/display-name propagation ([`personas/update.rs:140-184`](https://github.com/block/buzz/blob/desktop-v0.5.8/desktop/src-tauri/src/commands/personas/update.rs#L140-L184)).

## Reproduction observed

1. Set a persona to `parallelism = 3`.
2. Start an already-linked instance.
3. Observe that it starts with `BUZZ_ACP_AGENTS=10`.
4. Restart it repeatedly; it continues to use 10 while the persona dialog shows 3.
5. Edit the instance record directly; only then does the spawned value change.

## User impact

The displayed configuration and actual runtime configuration disagree without a warning. `acp_command` is especially difficult to recover from because the instance-edit dialog is not reachable for an agent linked to a persona, so there is no UI path to correct the stale instance value.

## Possible resolutions

Either approach would make the behavior coherent:

1. Route `parallelism` and `acp_command` through the effective-config/live-persona resolution used by neighboring fields; or
2. Keep instance snapshots authoritative, but surface the divergence clearly in the UI.

I am not prescribing which ownership model is preferable; the key requirement is to avoid silently showing persona values that the linked instance will not run.