Resolve whether whole-pipe ClickPipe PATCH applies settings

Whole-pipe ClickPipe PATCH rejects a settings-only update and can return HTTP 200 while silently ignoring settings when another field changes. This is the unresolved behavior split from #794 so that #823 can close the reconciled insert-size bounds issue.

## Recorded production evidence

Source: #823, validated on 10 September 2026 using a disposable AWS `eu-west-1` service. This issue records that completed validation; no new live requests were made during the split.

Endpoint: `PATCH /v1/organizations/{organizationId}/services/{serviceId}/clickpipes/{clickPipeId}` (`clickPipeUpdate`). The request schema exposes `ClickPipePatchRequest.settings` through `ClickPipeSettings`.

- A settings-only PATCH returned HTTP 400 with `no fields to update`.
- Including a changed name returned HTTP 200, but changing `object_storage_max_insert_bytes` from **524,288,000** to **10,737,418,240** left the stored value at **524,288,000** across settings GETs at 0, 10, 20 and 30 seconds.
- The dedicated settings PUT accepted both inclusive bounds and settings GET confirmed the saved values.
- Out-of-range values were rejected with HTTP 400 and the corrected range on POST, PUT and PATCH-with-name. Numeric validation is therefore separate from the failure to apply valid PATCH settings.

The disposable pipes, service and test tables were deleted after the original validation.

## Reproduction

Use a disposable object-storage ClickPipe with `object_storage_max_insert_bytes` set to `524288000` and confirm it through settings GET.

1. Send the following body to the whole-pipe PATCH endpoint:

```json
{"settings":{"object_storage_max_insert_bytes":10737418240}}
```

Observed: HTTP 400, `no fields to update`.

2. Repeat with a name different from the pipe's current name:

```json
{"name":"patch-settings-repro-renamed","settings":{"object_storage_max_insert_bytes":10737418240}}
```

Observed: HTTP 200, but subsequent settings GETs still return `524288000`.

3. Send the same setting using `PUT .../clickpipes/{clickPipeId}/settings` and verify the saved value with GET. This is the working comparison and current workaround.

The JSON above reconstructs the request shapes from the recorded validation; it is not an archived raw HTTP transcript.

## Expected behavior and acceptance

- [ ] Resolve the documented whole-pipe PATCH contract: if settings updates are supported, settings-only PATCH must apply them and PATCH with other fields must apply them too. If intentionally unsupported, reject settings explicitly and align OpenAPI and client guidance; do not silently report success.
- [ ] Add regression coverage for settings-only and mixed-field PATCH with readback verification, and confirm rejected requests leave stored settings unchanged.
- [ ] Preserve the reconciled inclusive numeric bounds of 524,288,000–10,737,418,240 bytes across POST, PUT and PATCH validation.
- [ ] Carry forward #794's unanswered nullable-settings question: confirm and document whether `null` is accepted, rejected or resets the setting on create, whole-pipe PATCH and settings PUT. Nullable behavior was not changed or revalidated in #823.
- [ ] Update downstream client guidance and validation once the upstream behavior is settled.

## Workaround and related changes

Use `cloud clickpipe settings update` for existing-pipe settings changes, as documented by #823.

The numeric bounds were reconciled upstream in https://github.com/ClickHouse/control-plane/pull/40253; #822 refreshes the API snapshot and #823 aligns CLI validation. Those changes resolve #794's bounds scope but do not resolve this PATCH defect. This issue remains open independently of #823 and has no closing relationship to it.

Start at the clickPipeUpdate PATCH entry point and the ClickPipePatchRequest.settings schema, then compare its behavior with the dedicated settings PUT and GET flow. Reproduce settings-only and mixed-field requests against a disposable ClickPipe, including nullable settings, and add regression coverage with readback and unchanged-value checks. Done means the contract is settled, validation and client guidance agree, and valid settings are not silently ignored.

Written by the indexing model from the issue text.