Agent draft-create should support the same portable, non-secret configuration as draft-update

### Problem

`buzz agents draft-create` currently accepts `channel`, `display_name`, and
`system_prompt`. `draft-update` additionally accepts `runtime`, `provider`,
`model`, and `respond_to`.

That asymmetry means an agent can propose a configured update from chat, but
cannot propose the same configuration when creating a colleague. The owner has
to reconstruct those choices in the review dialog even though they are ordinary
non-secret fields already understood by the CLI and Desktop.

### Proposed boundary

For a first parity pass, make these optional fields use the same names,
validation, and semantics for both create and update:

- `runtime`
- `provider`
- `model`
- `respond_to`

Desktop should resolve runtime/provider/model combinations through the runtime
catalog and show the effective values in the normal editable review dialog.
Unknown keys and unavailable combinations should fail validation rather than be
silently dropped.

There are other non-secret candidates that the current UI can represent, but I
would like maintainer direction before expanding the portable contract:

- parallelism;
- instance name pool;
- reasoning effort; and
- selected-people access policy.

Selected-people update support already has active work in #3912, so this issue
should coordinate with that PR rather than duplicate it.

### Explicit non-goals

This field-parity change should not carry:

- environment variables, credentials, or secret references;
- executable MCP commands;
- managed-agent key export or secret return;
- automatic approval; or
- standing delegation / an `apply` intent.

Those fields change the authority and secret-handling model and need their own
design. The default here remains an editable owner-reviewed draft.

### Lifecycle honesty

The CLI's immediate relay response proves publication only; it does not prove
that Desktop retained, presented, dismissed, or applied the draft. I suggest a
separate, owner-signed encrypted lifecycle receipt contract so field parity does
not make delivery claims stronger than the implementation can prove. That can
land independently if it would make this issue too broad.

### Acceptance criteria

- Create and update share the maintainer-approved non-secret field set.
- Both the CLI builder and Desktop parser strictly allowlist and validate it.
- The review dialog displays the effective requested configuration and remains
editable before save.
- No request field bypasses explicit owner review.
- No secret-bearing or delegated-apply surface is introduced.

### Related work

- #1878 — original chat-first agent draft workflow
- #3115 — broader CLI Advanced parity discussion
- #3227 — scoped app-integration agent RFC
- #3610 — pending-draft FIFO
- #3912 — selected-people allowlist round trip
- #5063 — removal of the managed-agent creation secret modal