FOLLOW-UP: Discriminated union type for TargetedRangeOp.ops (from PR #108)

[adnaan]

Context

This follow-up was identified during the review of PR #108 (per-op targeted DOM mutation for range diff ops).

Source PR: #108
Suggested by: @claude[bot] (PR review, round-5 comment)

Task description

TargetedRangeOp.ops and morphdomOptions? in client/types.ts are currently typed as any[] and any:

```ts
export interface TargetedRangeOp {
rangePath: string;
ops: any[];
statics: string[];
staticsMap?: Record<string, string[]>;
idKey?: string;
}
```

The runtime switch in RangeDomApplier.apply() plus per-op return boolean enforces correctness, but a stricter type would catch malformed ops at compile time and make the union of valid op shapes explicit.

Original comment excerpt

The ops are discriminated union tuples (["r", string], ["u", string], etc.). Even a loose [string, ...unknown[]] type would make the switch exhaustiveness checkable and catch malformed ops in future callers.

Suggested action

Define a discriminated union covering all 6 op shapes:

```ts
export type RangeDiffOp =
| ["r", string] // remove
| ["u", string, Record<string, any>] // update
| ["i", string, any | any[]] // insert after
| ["a", any | any[], string[]?, { idKey?: string }?] // append
| ["p", any | any[], string[]?] // prepend
| ["o", string[]]; // reorder

export interface TargetedRangeOp {
rangePath: string;
ops: RangeDiffOp[];
statics: string[];
staticsMap?: Record<string, string[]>;
idKey?: string;
}
```

Then refactor the switch in apply() to be exhaustiveness-checked via never assertion in the default case.

Acknowledged trade-off

Touches the public type surface (UpdateResult.targetedOps). Additive only — existing consumers using any will keep working — but type changes can break tooling/IDE inference. Worth coordinating with any downstream typescript consumers.

---

Created by /prmonitor from PR #108 review comments.