Make architecture selection clearer and more user friendly

[JoeHCQ1]

Is your feature request related to a problem? Please describe

As a modern mac user (M-series processors) and a newcomer to UDS tasks who needs to work on an ARM processor but deploy to AMD64 clusters, the way the UDS CLI and UDS tasks select the target architecture is confusing enough to produce significant frustration.

1. If no architecture is specified, it assumes my processor's architecture. This is a bad assumption.

2. The -a flag exists but is largely ignored, or ignored depending on where in the command you locate it. Regardless, it seems unreliable such that I spent much time trying to debug elsewhere assuming the flag worked, when in fact, the flag was still not taking effect.

3. The the UDS_ARCH variable is visible in the job yaml, especially in the tasks in uds-common, but is not a shell env variable despite being referenced via the $. This is another thing I tried setting to get the desired architecture, and failed. If I understand correctly, it's a reference to something inside the UDS CLI. As long as this variable is visible I expect users will keep being led astray by it. If it can't be made invisible, perhaps the name UDS_USER_ARCH would make it clearer it's an environmental constant, not an environment variable.

4. The key to understanding all of this is not intuitively derivable from the visible components of the system + past experience with similar tools. It requires reading and recalling this particular part of the docs. I'd suggest avoiding this kind of increase in cognitive load if at all possible.

Describe the solution you'd like

1. Ideally don't assume. Just require that the value be set.
2. If assumption is required, log when the assumption is made, that helps me know where my use of UDS tasks isn't producing the desired result. That would save me lots of time debugging.
3. If UDS_ARCH can't be made into a env variable we can set to override, change it's name to clearly be a constant, such as UDS_USER_ARCH or UDS_USER_SYS_ARCH to be even clearer.
4. Catch the -a/--architecture flag if a user passes it to UDS or remove it.
5. If still relevant, bring up the existence and preeminence of the UDS_ARCHITECTURE env variable in the help docs that come out of the CLI tool.

[zachariahmiller]

100% agree that this belongs in this repo vs maru. on the fence about bug or feature, but i think you summed it up reasonably.

For what its worth, i agree the ux here is confusing. Its especially frustrating when combined with the only.cluster.architecture: amd64 being set on some zarf packages.

As for the specific case you had listed, for reference in case anyone else has a similar issue the way to work past using system arch by default and overriding it optionally in tasks is as follows:

# tasks.yaml

variables:
  - name: ARCH
    default: ${UDS_ARCH}

tasks:
  - name: example
    description: "Example task"
    inputs:
      architecture:
        description: The architecture of the package to create
        default: ${ARCH}
    actions:
      - cmd: echo ${{ .inputs.architecture }}

$ uds run example
arm64  
$ uds run example --set ARCH="amd64"
amd64

notably, this would also work with the with key like so:

includes:
  - create: https://raw.githubusercontent.com/defenseunicorns/uds-common/v1.2.2/tasks/create.yaml
variables:
  - name: ARCH
    default: ${UDS_ARCH}
tasks:
  - name: create-dev-package
    description: Create the Valkey package
    inputs:
      architecture:
        description: The architecture of the package to create
        default: ${ARCH}
    actions:
      - task: create:package
        with:
          options: "--skip-sbom"
          architecture: "${{ .inputs.architecture }}"