Validate operation value arity in propose_operations

[xTITUSMAXIMUSX]

Problem

The generic write driver passed each op's comma-joined value straight through to VyManager without checking how many args it contained. When a value carried the wrong number of args — most commonly the subject re-included, e.g. "dum10,10.100.10.10/32" for a 1-arg address op — nothing caught it locally. It was only rejected at the device as an opaque HTTP 400 from /configure, with the real VyOS error swallowed upstream, making it very hard to diagnose.

Changes

• propose_operations now checks the comma-separated arg count against the op's expected post-subject arity and raises a clear error at propose time — naming the expected args and reminding that the subject is supplied via fields, not the value.
• describe_feature_operations now exposes per-op value_args and value_arg_count (the args the value must supply, with the subject stripped) plus a sharper note, so callers see the exact value shape up front instead of inferring it from a subject-mixed arg list.
• Bump version to 0.1.2 (also syncs __init__.__version__, which had lagged at 0.1.0).

Tests

Adds coverage for: subject-in-value rejection, correct single-value accepted, too-many-args on a non-subject feature, and the enriched describe output/note. Full suite (71 tests), ruff check, and mypy all pass.