Unblock postgres_instance_config PATCH (#163)

[sdairs]

Summary

• Flip every PgConfig field (23) plus both PostgresInstanceConfig nested fields (pgConfig, pgBouncerConfig) to Option<T> with skip_serializing_if = "Option::is_none", so Client::postgres_instance_config_patch can express a real partial update. Pair the change with 25 OPTIONALITY_EXEMPTIONS entries in spec_coverage_test.rs; the staleness detector will tell us automatically when upstream fixes the spec.
• Re-enable the deferred PATCH round-trip in integration_postgres_test.rs (GET baseline → PATCH max_connections → poll-until-applied → PATCH back).
• Add a gated CLICKHOUSE_CLOUD_POSTGRES_CONFIG_PROBE=1 probe phase that fires the 6 × 2 behaviour-matrix scenarios from the issue's follow-up comment via raw reqwest and prints a markdown table on stderr. Default off so it doesn't run on every integration test.

Closes #163.

Follow-ups

• Capture the behaviour matrix and file the upstream spec issue (draft text already lives in Cover postgres_instance_config_post + postgres_instance_config_patch #163). To capture:

  CLICKHOUSE_CLOUD_POSTGRES_CONFIG_PROBE=1 \
    cargo test -p clickhouse-cloud-api --test integration_postgres_test cloud_postgres_crud_lifecycle -- --ignored --nocapture
  

• Once the spec is fixed upstream, the new OPTIONALITY_EXEMPTIONS entries become stale and field_optionality_matches_spec will flag them — remove the block.

Test plan

• cargo build --tests (whole workspace)
• cargo clippy --tests
• cargo test (all non-ignored tests pass)
• cargo test -p clickhouse-cloud-api --test spec_coverage_test field_optionality_matches_live_spec -- --ignored — 25 new exemptions all register against the live spec, no stale entries
• cargo test -p clickhouse-cloud-api --test integration_postgres_test -- --ignored --nocapture (live cloud creds required)
• CLICKHOUSE_CLOUD_POSTGRES_CONFIG_PROBE=1 cargo test -p clickhouse-cloud-api --test integration_postgres_test -- --ignored --nocapture — capture behaviour matrix for upstream

🤖 Generated with Claude Code

[sdairs]

Blocked: response shape returns string-encoded numbers

Marking this PR as draft and blocked. The request-shape fix in this branch works (PATCH/POST now succeed against the live API per the captured matrix), but the response shape can't be deserialised into the spec-declared types.

What we see

For pgConfig fields the spec declares as integer / number, the live API returns the value wrapped in a JSON string. Example response from a successful PATCH (matrix body 2):

{"result":{"pgConfig":{"max_connections":"200"},"pgBouncerConfig":{},"message":"…"}}

max_connections is "200" (string), not 200 (number). Deserialising into Option<i64> fails with:

JSON error: invalid type: string "107", expected i64 at line 1 column 46

This affects every strictly-numeric pgConfig field — max_connections, effective_io_concurrency, max_worker_processes, max_parallel_workers, max_parallel_workers_per_gather, max_parallel_maintenance_workers, random_page_cost. The mixed-type fields (type: ["string","integer"] like work_mem, *_timeout, etc.) are already typed as serde_json::Value, so they're unaffected.

The same asymmetry applies in both directions: requests must send JSON numbers (string-encoded values are rejected), but responses come back string-encoded. So we can't just flip the field types — the model would then serialise wrong on the request side.

Why this PR is paused

A client-side workaround (custom deserialize_with that accepts both number and string) was considered and rejected — we don't want to mangle types to paper over an API inconsistency. This needs to be fixed on the API side: response numeric fields should match the spec's declared integer/number types.

Next steps

• File / link upstream API issue for response-side type mismatch on pgConfig numeric fields
• Unblock once the API returns numbers as numbers
• Re-enable the gated integration round-trip (patch pgConfig.max_connections in integration_postgres_test.rs)