Declared output cpuModel is never set

[ModeSevenIndustrialSolutions]

Summary

action.yml declares a cpuModel output, but nothing in the action ever sets it. Consumers reading steps.<id>.outputs.cpuModel always receive an empty string.

Evidence

cpuModel appears exactly once in the entire repository — its own declaration in action.yml (line 41 on main):

$ grep -rn "cpuModel" --include="*.ts" --include="*.yml" --include="*.yaml" --include="*.md" . | grep -v node_modules
./action.yml:41:  cpuModel: # id of the output

Comparing the declared outputs against the core.setOutput calls in the bundle:

declared outputs      : 16
setOutput names found : 15
declared but never set: ['cpuModel']
set but not declared  : none

src/main.ts computes and emits cpu, cpuVendor, cpuNumProc, gpuVendor, gpuModel and the rest, but never computes a cpuModel value. It is also absent from the hwBom object that gets logged:

const hwBom = {
  [workflowRun]: {
    cloud, instanceType, uname,
    cpu, cpuVendor, cpuNumProc,     // <- no cpuModel
    hostname, gpuVendor, gpuModel,
    memTotal, diskTotal, diskUsed, diskFree
  }
}

Is it actually needed?

Possibly not. The existing cpu output already carries the CPU model name:

const cpu = runCommand(
  'cat /proc/cpuinfo |grep "model name"|sort -u|cut -d ":" -f2|awk \'{$1=$1};1\''
)

So cpuModel looks vestigial — the value a caller would expect from it is already available via cpu. Note the asymmetry with the GPU pair, where both gpuVendor and gpuModel are genuinely populated; for CPU only cpuVendor has a counterpart, and cpu is doing the cpuModel job under a different name.

Impact

Low but silent. A workflow consuming cpuModel gets an empty string with no warning, and the empty value propagates into whatever report or artefact it feeds.

Options

1. Remove the output. Cleanest if it is genuinely redundant with cpu, but it is a public interface change and would warrant a major version bump.
2. Populate it. Add a core.setOutput('cpuModel', ...) in src/main.ts (and add it to the hwBom payload for consistency), then rebuild the committed dist/. Needs a decision on whether it should differ from cpu.
3. Document it as deprecated and leave the behaviour alone.

I have deliberately not picked one, since each has interface consequences that are the maintainer's call.

Context

Found while preparing #287, which removes composite-only value: keys from this JS action's outputs block. That PR is a pure metadata correction and deliberately leaves this behavioural question alone. Both were surfaced by an estate-wide sweep for dangling steps.<id>.outputs.* and orphaned env.* references.