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

先阅读 #83 以及对 #120 和 #137 的引用，然后按要求使用 /grilling 和 /domain-modeling。通过讨论解决优先级、Run.Path、默认值、可发现性以及 Pester 5/6 之间的差异。当优先级契约已在此处记录得足够详细，使 #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.