Align Json's public commands with the PowerShell function standard #31

Context and request

None of Format-Json, Import-Json, or Export-Json declares [OutputType()], and none documents .INPUTS, .OUTPUTS, or .NOTES. The MSX PowerShell function standard treats [OutputType()] and the matching .OUTPUTS block as the contract between a function and its callers, and PlatyPS renders those sections into the published reference at psmodule.io/Json, so their absence leaves the generated documentation without an output contract.

Beyond the missing contract, the functions diverge from the standard in ways that change behaviour for callers: Format-Json uses return $json to emit, catches its own errors and emits Write-Error without rethrowing — so an invalid input yields $null on the success stream rather than a terminating failure — and Export-Json carries an empty begin {} block. Parameter sets are named FromString and FromObject, where the standard asks for prose phrases that read naturally in Get-Help syntax output.

Scope

In scope: the declared output contract, comment-based help completeness, function structure, error semantics, and parameter set naming for the three existing public commands.

Out of scope: the behavioural defects in -Depth handling and _SourceFile injection, which are tracked separately, and any new commands.

Aggregate acceptance criteria

• Every public command declares [OutputType()], scoped per parameter set where sets return different types.
• Every public command documents .INPUTS and .OUTPUTS in the PlatyPS blank-line format, with a description for each entry, and .OUTPUTS matches [OutputType()].
• Invalid input produces a terminating error a caller can catch, not a silent $null.
• Get-Help <Command> shows parameter set names that read as scenarios.
• The generated reference pages on the documentation site show the output contract.

Technical decisions

Renaming parameter sets changes Get-Help syntax output but not any calling convention, since the sets are selected by which parameter is supplied and no caller passes a set name. This is not a breaking change.

Changing Format-Json from Write-Error-and-continue to a terminating failure is observable: callers who currently receive $null from malformed input will start seeing an exception. This is the correct behaviour per the standard and matches what the existing test Should throw error on invalid input already asserts, but it warrants a Minor label rather than Patch.

The two children split the contract-only change from the structural change so the first can merge quickly and independently.

Implementation plan

Delivery is tracked through the native sub-issues on this PBI.