Modules declare themselves with a descriptor instead of six registration edits #17

Chapter 7 of the manual documents adding a Module as "four small edits, all in
files you already have." It is really six, across three files, and the manual is
honest about it — which is the tell. A seam that needs a six-item checklist
outside the Module is not a seam.

Today, src/Config-MyThing.ps1 must also be declared in:

1. Invoke-WcdConfiguration.ps1 -> the $modules array
2. Invoke-WcdConfiguration.ps1 -> the switch ($modName) dispatch arm
3. WcdHelpers.ps1 -> Get-WcdModuleProgressPlan
4. WcdHelpers.ps1 -> Get-WcdTechnicalStepLabels
5. Invoke-WcdConfiguration.ps1 -> $T.Checklist, in both language tables
6. Invoke-WcdConfiguration.ps1 -> Get-WcdFinalChecklistEntries

Miss one and nothing fails. A missing progress-plan entry drops the Module from
the run silently — the $moduleStepPlan.ContainsKey guard treats "not planned"
and "planned as empty" differently, and a Module absent from the hashtable runs
with a $null step list. A missing $T.Checklist key renders a blank label on
the checklist.

The descriptor

Each Config-*.ps1 exports one function returning what the orchestrator needs:

function Get-WcdMyThingDescriptor {
    param([pscustomobject]$ExecutionOptions, [hashtable]$Config)

    [pscustomobject]@{
        Name  = 'Config-MyThing'
        Steps = @(
            @{ Key = 'MyStep';      Label = 'My thing' }
            @{ Key = 'MyOtherStep'; Label = 'My other thing' }
        )
        Rows  = @(
            @{ Label = 'MyThing'; Steps = @('MyStep', 'MyOtherStep') }
        )
        Invoke = { param($ctx) Set-WcdMyThingConfiguration -LogPath $ctx.LogPath -ProgressCallback $ctx.ProgressCallback }
    }
}

The orchestrator globs src/Config-*.ps1 in run order, dot-sources each, calls
its descriptor, and builds the progress plan, the step labels and the checklist
rows from what comes back. Get-WcdModuleProgressPlan and
Get-WcdTechnicalStepLabels become the thing that assembles descriptors
rather than the thing that hardcodes twelve Modules.

What the descriptor has to handle

The current hardcoded tables are not uniform, and the descriptor has to absorb
that or it is not an improvement:

• Form-Factor-dependent Steps. Config-Power plans five Steps on a Laptop
  and two on a Desktop; the checklist row has the same split. Hence
  $ExecutionOptions as a descriptor parameter.
• Manifest-derived Steps. Config-Applications and Config-Printer get
  their Step keys and labels from the manifest at runtime. Hence $Config.
• Conditional Modules. Config-Identity plans zero Steps when the
  technician declined both, and the orchestrator skips the Module entirely.
  An empty Steps array must keep meaning exactly that.
• Rows that are not one-per-Module. Config-Disk produces two rows,
  Config-WindowsUpdate folds two Steps into one row, and the restart row is
  raised from Results across two Modules. The restart row is special enough to
  stay in the Diagnostic rather than move into a descriptor.
• Run order. Glob order is alphabetical, not run order. Keep an explicit
  ordered list of Module names, or add an Order field — but that is one
  registration point, not six.

Ordering

Do #16 first. This rewrites Get-WcdFinalChecklistEntries, and that
function currently has no test to rewrite it against.

Done when

• Every Config-*.ps1 exports a descriptor function
• The orchestrator discovers Modules instead of hardcoding $modules
• The switch ($modName) dispatch is deleted
• Get-WcdModuleProgressPlan and Get-WcdTechnicalStepLabels assemble from descriptors
• A descriptor missing a required field fails at load, loudly
• Laptop and Desktop runs plan the same Steps as before
• A run declining both identity options still skips Config-Identity
• Checklist output byte-identical before and after, in both languages
• tests/ gains a descriptor-contract test every Module is run through
• Manual chapter 7 rewritten: one file, one code block