Add permissions group-update for existing groups' object and field controls

[jbedient-kizen]

Problem

Permission groups could be created with shaping settings but never adjusted afterwards — there was no way to raise or lower a control on a group that already exists.

Solution

kizen permissions group-update <group> --settings-file <f> takes the same op shapes group-create --settings-file already accepts, so the settings format has a second consumer rather than a second dialect. Dry-run shows current -> target per op, read from the live group.

The substance of this PR is what happens when the server does not honour the level you asked for. object-update reports that in its response body rather than 4xx-ing, and three different situations look identical on the wire. They are now separated:

1. Out of range for the control — e.g. associated_records: none, which has no none in its allowed_access. Rejected at plan time, before any write.
2. Legal but normalized by a cross-field rule — e.g. associated_records clamped up to satisfy associated_records >= all_records. Reported as adjusted with a plain-language message. Not a failure: the server applied a value this design deliberately delegates to it, so the exit code stays 0.
3. Control has no entry in the group at all — inserted at none and cannot be raised. Still failed, loudly.

Testing

bin/check.sh — all five steps pass: 1455 passed, 4 skipped (+13).

All three outcomes were verified live against a disposable tenant, not just unit-tested:

all_records = remove              -> ok        exit 0
associated_records = view         -> adjusted  exit 0
  "requested view, server normalized to remove (…corrected by rule.)"
associated_records = none         -> PlanError before any write
control absent from group         -> failed    exit non-zero

Design notes / tradeoffs

Case 2 cannot be caught at plan time without reimplementing the server's rule engine — the outcome depends on the group's combined final state, including ops earlier in the same plan. That is deliberate: the reason this uses object-update instead of hand-building a full-group PUT is precisely so the server owns those rules.

adjusted is a new value on OperationResult.status, visible in apply --json. Nothing consumes it today, but it is a schema addition rather than an internal detail, so it is worth a deliberate look.

The plan-time range check also covers group-create --settings-file, which was reachable by the same false-failure path. That widens this branch slightly beyond group-update; leaving a known bad path in place to keep the diff narrow seemed worse.

Fifth of six stacked branches.