fix(cli): omit null/empty request fields so older instances accept them

[t0saki]

Summary

The CLI unconditionally attaches optional fields to the find / search / add_resource request bodies — args as an empty {}, and tags / context_type as null — even when the user never set them. Because OpenViking kernels declare model_config = ConfigDict(extra="forbid") on these routes, any instance that predates a given field rejects the entire request with body.<field>: Extra inputs are not permitted. This patch stops sending those empty/null fields, and turns the raw rejection into an actionable hint when a field really is set but unsupported.

Problem

The breakage is purely a field-set mismatch on extra="forbid" routes: the set of fields the CLI sends must be a subset of the fields the target instance's model defines. It is not strictly "CLI newer than server" — it bites in both directions (newer CLI sending a not-yet-added field, or older CLI still sending a field the kernel later renamed/removed).

Concrete cases observed against the Volcengine endpoint (same gateway, different instance versions selected by API key):

• ov add-resource <url> against a pre-feat(resource): 支持飞书用户 token 导入 #2549 instance → body.args: Extra inputs are not permitted (kernel model has no args field; the route has been extra="forbid" since fix(http): replace temp paths with upload ids #1012). The user never passed --args; the CLI sends args: {} regardless.
• ov find <query> against a strict pre-Set tags #2706 instance → body.tags: Extra inputs are not permitted (FindRequest became extra="forbid" in feat(core): add actor peer filesystem view #2594 but the tags field only landed in Set tags #2706). The user never passed --tags; the CLI sends tags: null regardless.

Fix

• Add compact_request_body() and apply it in find / search / add_resource: drop null-valued keys and an empty args object right before sending. Scoped to these read/create routes only, where a missing optional field and an explicit null are equivalent — deliberately not applied globally in post, since null may carry "clear this field" semantics on a future update/PATCH route. This generalizes the backward-compat convention already used for create_parent.
• When a field is explicitly set but the instance does not support it, detect the pydantic Extra inputs are not permitted rejection (extra_forbidden_field) and render a version-mismatch hint instead of the opaque API error, plus an ov health action to check the instance version.

Verification

• New unit tests: compact_request_body_drops_null_and_empty_args, compact_request_body_keeps_non_empty_args, extracts_extra_forbidden_field, ignores_non_extra_forbidden_errors — all pass.
• cargo test -p ov_cli --bins: all tests pass except one pre-existing failure (help_ui … missing clap command set-tags) that is unrelated to this change and reproduces on main with this patch stashed.
• End-to-end: a debug build of the patched CLI now returns results for ov find against an instance that previously failed with body.tags: Extra inputs are not permitted.

[ZaynJarvis]

lgtm, fixes compatibility issue