[BUG] Argdump -> Boutiques: "Number" type not inferred correctly when choices are defined

[michellewang]

In the argdump below, both default and choices are clearly numbers, and the type is int, but somehow it is being coerced into a string.
Seems to have been missed by 070f4ea.

  {
    "$schema": "https://niwrap.dev/argdump/schema-v1.json",
    "$env": {
      "python_version": "3.13.15",
      "python_implementation": "CPython",
      "platform_system": "Linux",
      "platform_release": "6.17.0-1022-azure",
      "platform_machine": "x86_64",
      "argdump_version": "0.1.3"
    },
    "prog": "petprep",
    "description": "PETPrep: PET PREProcessing workflows v0.1.dev1+g2f5176c",
    "formatter_class": "ArgumentDefaultsHelpFormatter",
    "actions": [
      {
        "option_strings": [
          "--pet2anat-dof"
        ],
        "dest": "pet2anat_dof",
        "action_type": "store",
        "default": 6,
        "type_info": {
          "name": "int",
          "builtin": true
        },
        "choices": [
          6,
          9,
          12
        ],
        "help": "Degrees of freedom when registering PET to anatomical images. 6 degrees (rotation and translation) are used by default."
      }
   ]
  }

Resulting Boutiques descriptor:

{
  "schema-version": "0.5+styx",
  "name": "petprep",
  "description": "PETPrep: PET PREProcessing workflows v0.1.dev1+g2f5176c",
  "command-line": "petprep [PET2ANAT_DOF]",
  "inputs": [
    {
      "id": "pet2anat_dof",
      "type": "String",
      "value-key": "[PET2ANAT_DOF]",
      "description": "Degrees of freedom when registering PET to anatomical images. 6 degrees (rotation and translation) are used by default. (Default: \"6\")",
      "optional": true,
      "command-line-flag": "--pet2anat-dof",
      "value-choices": [
        "6",
        "9",
        "12"
      ],
      "name": "pet2anat_dof"
    }
  ]
}

[nx10]

Fixed in #90.

The type wasn't being lost in the argdump parser. resolveTerminal returns early on choices before it ever consults type_info, and the solver already canonicalizes clean integer literals back to numbers, so the binding was correct. The Boutiques backend was the problem: mapUnion hardcoded String for any all-literal union, and finalizeInput then stringified the numeric choices to keep the input schema-valid. That's why 070f4ea missed it.

Your case now emits "type": "Number", "integer": true, "value-choices": [6, 9, 12]