Define recipe parameter limits and graceful oversized-recipe behavior

**Describe the bug**

The Desktop recipe-parameter request path has no documented limits for parameter count, options per select parameter, field string lengths, or aggregate request size. The parameter modal renders every accepted field and option synchronously, so sufficiently large but structurally valid recipes can make the renderer unresponsive and there is no stable contract for deciding whether the backend should reject them or the client should handle them differently.

---

**To Reproduce**

1. Generate a valid recipe with a progressively increasing number of user-prompt parameters and select options.
2. Open the recipe in Desktop so the parameter modal is displayed.
3. Observe that every field and option is retained and rendered without a cardinality or aggregate-size limit.

---

**Expected behavior**

Goose should define supported recipe-parameter limits and handle recipes beyond that contract without making Desktop unresponsive. The accepted design should clarify whether limits are enforced in recipe validation, defensively in the ACP client, through modal virtualization/pagination, or through a combination of those approaches.

---

**Screenshots**

Not applicable.

---

**Please provide the following information**

- **OS & Arch:** All supported Desktop platforms
- **Interface:** UI
- **Version:** Current `main`
- **Extensions enabled:** Not applicable
- **Provider & Model:** Not applicable

---

**Additional context**

Before implementation, maintainers need to choose the supported maximum parameter count, maximum options per parameter, string/aggregate size bounds, and an acceptable rendering behavior for large recipes. Those decisions determine both the validation contract and whether the modal needs virtualization or pagination.

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).