Agent definition Parallelism placeholder implies 1 while unset values use the backend default

**Describe the bug**

The optional **Parallelism** field in the agent definition create/edit flow displays `1` as its placeholder.

However, `1` is not the effective value. Leaving the field blank omits `parallelism` from the definition, so an instance created from that definition receives the Desktop backend default instead.

This makes the UI appear to configure one worker while the effective parallelism may be different and significantly higher.

On Buzz Desktop 0.4.26, leaving the field blank resulted in an effective parallelism of 24.

**Steps to reproduce**

1. Open the agent definition create or edit flow.
2. Expand the advanced settings.
3. Observe that the empty **Parallelism** field displays `1`.
4. Leave the field untouched and save the definition.
5. Create a new agent instance from that definition.
6. Start the instance.
7. Inspect the resulting managed-agent configuration or the `buzz-acp` startup log.
8. Observe that the effective parallelism is not 1.

**Expected behavior**

The UI should clearly communicate the effective parallelism that will be applied when the field is left blank.

For example, it could either:

* display the resolved effective value in the field, or
* leave the field visibly empty and show helper text such as `Default: 10`.

The displayed default and backend default should ideally come from the same source of truth.

**Version and platform**

* Buzz version: 0.4.26
* OS: macOS 15.6.1

**Logs / additional context**

The resulting managed-agent configuration contained:

```json
"parallelism": 24
```

The corresponding `buzz-acp` startup log reported:

```text
agents=24
```

The effective parallelism was therefore 24, not 1.

Current `main` also appears inconsistent:

* UI placeholder: `1`
* `DEFAULT_AGENT_PARALLELISM`: `10`

The default was reduced from 24 to 10 in #3038, but the placeholder still communicates 1.

This mismatch makes agent concurrency and resource usage difficult to understand. It can also invalidate concurrency or queueing tests: a user may believe they are testing with one worker while the agent actually has many workers available.

I encountered this while testing queued-turn visibility. I initially interpreted the displayed `1` as the effective configuration, but later found that the agent was running with parallelism 24.

Related work:

* #2631 — default parallelism 24 and its resource impact
* #3038 — reduces `DEFAULT_AGENT_PARALLELISM` from 24 to 10

I searched open issues and PRs but did not find one specifically covering the mismatch between the Parallelism placeholder and the effective backend default.

Start by locating the agent definition Parallelism field and the DEFAULT_AGENT_PARALLELISM constant, then trace how an unset value is omitted and resolved by the backend. Confirm the UI placeholder and backend default use the same value or clearly communicate the resolved default; done when the displayed guidance matches the effective behavior and relevant tests pass.

Written by the indexing model from the issue text.