Investigate live u64-max service-setting readback precision

## Validated scope and current-PR plan — 2026-09-11

This section records the QA review and the current decision to finalize existing PRs without opening new PRs. It supersedes the proposed routing/fix suggestions in the original report below; the original observations are retained. Central plan: #757.

### Work for the existing PRs

Implementation status: the checked sub-items below are implemented on the existing PR branches and validated locally on combined head `82b374816a917cbac3a68194659beaaa5c7c9087`. Required final-head Cloud CI and merging remain pending; this issue stays open. See #757 for the combined validation and CI status.

- [x] #781 — Prevent lossy numeric input in both `--setting` and settings-file/stdin maps; retain exact in-range signed/unsigned integers. Cover u64::MAX, overflow and exponent inputs at the wire boundary. Coordinate with #822 without making this earlier PR depend on a descendant.

The existing-PR work addresses confirmed CLI input loss. Keep the live u64-max readback investigation explicit; do not close it as fixed by an unrelated parser change.

### Validation and corrections

Partially confirmed and needs correction. Mock capture preserves 18446744073709551615 exactly on request and response. 99999999999999999999 becomes 1e+20 before HTTP. 1e3 becomes 1000.0, which preserves numerical value; lexical normalization alone is not corruption. #786/#787 concern response types/display. #822 already offers a strict string/i64/u64 request type, while CLI #781 still parses generic JSON values. Reject demonstrably lossy literals without silently changing their JSON type; investigate the live u64-max rounding separately.

---

## Original QA report

Found in the 2026-09-11 QA sweep of the combined PR stack at [`d2c37f81`](https://github.com/ClickHouse/clickhousectl/commit/d2c37f814fff53fe68d636e34103e2d0550bf84d), top PR #823, installed release build (package version still 0.4.2). Reproduced behaviour only; no implementation included.

Severity: medium. The typed-settings work (#759/#779/#795) is otherwise verified good: small ints, strings and bools round-trip with correct JSON types.

```sh
clickhousectl cloud service settings set "$SVC" --setting 'max_query_size=18446744073709551615'
# max_query_size: 1.8446744073709552e+19
clickhousectl cloud service settings get "$SVC" max_query_size --json
# {"name":"max_query_size","value":1.8446744073709552e+19}
clickhousectl cloud service settings set "$SVC" --setting 'max_query_size=99999999999999999999'
# max_query_size: 1e+20 # accepted, stored, listed as 1e+20
clickhousectl cloud service settings set "$SVC" --setting 'max_query_size=1e3' # stored as 1000
```

Literals that do not fit `u64`/`i64` fall back to `f64` and are stored in scientific notation; the schema declares the setting `type: integer`. Suggested: for integer-typed schema entries reject non-integral or out-of-range literals client-side (the schema is already fetched by `settings schema`), or at minimum keep the literal as a string rather than an `f64`.

Reproduce the live `settings set` and `settings get --json` commands with u64::MAX, then compare their displayed values with the exact request and response at the wire boundary. Trace the CLI settings readback path alongside the fetched schema and determine whether rounding occurs in the client or service; document the finding separately from the parser work tracked in #757.

Written by the indexing model from the issue text.