ArgParser: support positional args inside union cases

Removes the last restriction of the positional-args-with-unions plan:
a [<PositionalArgs>] field may now live inside a union case's payload
record, so each alternative can convert the positional stream at its
own field's type. Two sinks in mutually exclusive cases may share
their addressing forms (a keyed --rest token means the same thing
whichever case wins); a form still may not collide with any named
argument. Generation rejects only what is genuinely unsound: two sinks
in one product (argv holds a single positional stream), Collect-mode
sinks anywhere a union is in play (a mistyped case-selecting argument
would be silently collected), and unprovable flag-like settings.

Selection remains purely structural, before any conversion: named
arguments select cases; a keyed positional form unique to one
alternative selects it structurally; bare tokens never select (except
that a sink present in only one case makes bare tokens pin that case);
and parseability at some case's element type never influences the
choice. Help renders each case's positional args inside its group.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: Smaug123

CHANGELOG.md

@@ -1,5 +1,11 @@
 Notable changes are recorded here.
 
+# Unreleased
+
+The `ArgParserGenerator` now supports positional args together with discriminated-union args, as long as the positional args reject unrecognised flag-like tokens (the default; `[<PositionalArgs true>]` remains banned in combination with a union).
+A `[<PositionalArgs>]` field may sit beside the union-typed field (the positional stream is shared by every alternative), or inside the cases' payload records (each alternative converts the stream at its own field's type).
+Case selection is purely structural and happens before any value conversion: named arguments (and, where unique to one alternative, the keyed `--rest=value` form of a positional field) select the case, bare positional tokens never do, and whether a token happens to parse at some case's element type never influences which case wins.
+
 # WoofWare.Myriad.Plugins 10.2.3
 
 The `ArgParserGenerator` now permits a `[<PositionalArgs>]` field at the top level alongside (though not within) a discriminated-union arg, as long as the positional sink rejects unrecognised flag-like tokens (the default; `[<PositionalArgs true>]` remains banned beside a union, because that would make it very confusing when you typo a DU-case-selecting flag).

ConsumePlugin/DuArgs.fs

@@ -105,3 +105,50 @@ type CommandAndPositionals =
         [<PositionalArgs false>]
         Paths : string list
     }
+
+type FooModeArgs =
+    {
+        Foo : int
+
+        [<PositionalArgs>]
+        Rest : int list
+    }
+
+type BarModeArgs =
+    {
+        Bar : int
+
+        [<PositionalArgs>]
+        Rest : string list
+    }
+
+/// The motivating example of per-case positional args: both cases collect the positional
+/// stream (addressable under the same default `--rest` form, which is fine because the cases
+/// are mutually exclusive), but convert it at different types. Selection happens before any
+/// conversion, so whether a token parses as int never influences which case wins.
+[<ArgParser>]
+type FooBarMode =
+    | FooMode of FooModeArgs
+    | BarMode of BarModeArgs
+
+type PullArgs =
+    {
+        [<ArgumentLongForm "source">]
+        From : string
+
+        [<PositionalArgs>]
+        Refs : string list
+    }
+
+type StatusArgs =
+    {
+        Verbose : bool option
+    }
+
+/// Positional args in only one case: the other (all-optional) case is the empty command
+/// line's fallback, and a bare token structurally selects Pull because only Pull can consume
+/// it.
+[<ArgParser>]
+type GitLike =
+    | Pull of PullArgs
+    | Status of StatusArgs