Support parsing options after unknown positional arguments (permissive/interspersed mode)

[taras]

Problem

Currently, configliere stops parsing options when it encounters a positional argument that isn't defined in the schema. This makes it difficult to implement two-phase parsing where phase 1 only needs a subset of fields.

Example

const bootstrap = program({
  name: "myapp",
  config: commands({
    run: {
      description: "Run command",
      ...object({
        config: { description: "Config file", ...field(z.string().optional()) },
        watch: { description: "Watch mode", ...field(z.boolean().optional()) },
      }),
    },
  }),
});

// This works - flags before positional
bootstrap.parse({ args: ["run", "--watch", "--config", "foo.json", "./suite"], envs: [] });
// Result: { config: { config: "foo.json", watch: true } }, remainder: { args: ["./suite"] }

// This doesn't work as expected - flags after positional
bootstrap.parse({ args: ["run", "./suite", "--watch", "--config", "foo.json"], envs: [] });
// Result: { config: {} }, remainder: { args: ["./suite", "--watch", "--config", "foo.json"] }

When ./suite appears first, configliere stops parsing and leaves --watch and --config in the remainder unparsed.

Use case

We want to implement a two-phase parse:

1. Bootstrap phase: Parse only early concerns (--config, --watch) before loading plugins
2. Command phase: Parse full command schema including plugin-contributed fields

This requires bootstrap to extract --config and --watch regardless of where positional arguments appear in argv. Users commonly write run ./suite --watch rather than run --watch ./suite.

Possible solutions

1. Permissive mode — Continue parsing known options even after unknown positionals, collecting unknowns in remainder
2. Interspersed arguments option — Flag to allow options anywhere in argv (like GNU getopt's default behavior)
3. Explicit unknown-positional handling — A way to declare "there may be unknown positionals, keep parsing options"

Current workaround

We include the positional field (suite) in the bootstrap schema even though we don't need it for phase 1. This is fragile because:

• We have to duplicate positional definitions between bootstrap and full schema
• If plugins add new positional arguments, bootstrap won't know about them and flags after those positionals won't be parsed