Design: precedence contract for a consumer-supplied PesterConfiguration (#83)

Part of #120 (Phase 3 — API improvements). Blocks #83.

Question

When a consumer supplies their own [PesterConfiguration] object via $PSBPreference.Test.Configuration, what wins — their object, or the existing $PSBPreference.Test.* settings?

#83 raises this and leaves it open. It is the one genuinely undesigned item left in v1.0.0, and it defines public API surface that freezes at 1.0.0 — getting the precedence wrong is a breaking change to undo later.

Note: #120 previously pointed at "joshooaj's design in #80". That pointer is stale — #80 is a different, already-closed request about Output.Verbosity and Run.SkipRemainingOnFailure. There is no existing design to implement.

Open questions

1. Precedence. Does the supplied object act as a base that $PSBPreference.Test.* overrides, or as a final say that PowerShellBuild only fills gaps in? A consumer who sets both and gets the opposite of what they expected is the failure mode to design against.
2. Run.Path. PowerShellBuild computes the test path today. If the consumer sets Run.Path on their object, is it honored, ignored, or an error? The advanced surface permits multiple paths, which the current single-path model has no answer for.
3. Opinionated defaults. Which settings does PowerShellBuild insist on regardless (code coverage output location, result file paths, CI-detection behavior) because the surrounding build tasks depend on them?
4. Discoverability. If a supplied setting is silently overridden, how does the consumer find out? Silent override is the worst outcome — worse than an error.
5. Pester 5 and 6. Test-PSBuildPester supports both majors and the #137 matrix verifies both. Does the configuration object surface differ between them in ways that affect the answer?

How to resolve

Conversation, not code — /grilling plus /domain-modeling. @joshooaj should be in it: they raised #83 and the design questions are theirs. A prototype of the merge logic is reasonable if the discussion stalls on something concrete.

Done when

The precedence contract is written down here in enough detail that #83 can be implemented without further design decisions.

Start by reading #83 and the references to #120 and #137, then use /grilling and /domain-modeling as requested. Resolve precedence, Run.Path, defaults, discoverability, and Pester 5/6 differences through conversation. Done means the precedence contract is documented here in enough detail for #83 to be implemented without further design decisions.