Drop Run.BeforeContainer option, keep the Pester.BeforeContainer.ps1 convention

[nohwnd]

Summary

The experimental BeforeContainer bootstrap shipped with two entry points:

1. the Run.BeforeContainer scriptblock[] configuration option, and
2. the repo-root Pester.BeforeContainer.ps1 convention file (resolved from Run.RepoRoot).

Having both created the inconsistent path story Frode raised in #2838: the file always
exposes a stable $PSScriptRoot/$PSCommandPath to anchor relative paths against, while
the scriptblock option only had the unstable $pwd and no file to anchor from.

This PR removes the configuration option and keeps only the zero-config convention file,
dot-sourced before each container in both sequential and parallel runs. One mechanism, one
consistent behaviour. (As Frode put it: "Do we need to support BeforeContainer as a
configuration option? While nice for debugging, it has some quirks like this.")

Compelling example

Put shared setup once at the repo root in Pester.BeforeContainer.ps1 and every test file –
sequential or parallel – gets it for free. Because it is a real file, $PSScriptRoot is stable
regardless of the working directory Invoke-Pester was called from:

# ./Pester.BeforeContainer.ps1  (at Run.RepoRoot, e.g. the .git root)
Import-Module -Name (Join-Path $PSScriptRoot 'tests/Helpers.psm1') -Force

$PSDefaultParameterValues['Mock:ModuleName']          = 'MyModule'
$PSDefaultParameterValues['InModuleScope:ModuleName'] = 'MyModule'
$PSDefaultParameterValues['Should-Invoke:ModuleName'] = 'MyModule'

# ./tests/Calculator.Tests.ps1 – no per-file bootstrap needed
Describe 'Calculator' {
    It 'adds' { Get-Answer | Should -Be 42 }   # helper came from the shared bootstrap
}

$c = New-PesterConfiguration
$c.Run.Path     = './tests'
$c.Run.Parallel = $true            # each worker runspace re-runs the same bootstrap
Invoke-Pester -Configuration $c

This removes the ~duplicated BeforeAll/Import-Module boilerplate every file would otherwise
repeat, and – crucially – makes it work under Run.Parallel, where each worker starts from a
clean runspace (the real-world ask from #2772).

Where this leaves Frode's 6.1.0 issues

Issue	Status after this PR
#2838 Inconsistent story for relative paths with BeforeContainer	Fixed. Only the file convention remains, which always has a stable $PSScriptRoot. The $pwd-only quirk is gone with the option.
#2839 Expose current container to BeforeContainer	Still open. Conditional per-file setup (if ($Container.Name -like '*.Integration.Tests.ps1')) is a separate feature and is not addressed here. Removing the option narrows it to "expose the container to the convention file".
#2825 Parallel debug output printed before the relevant test	Still open / unrelated to BeforeContainer (parallel diagnostic-output ordering).

Changes

• src/csharp/Pester/RunConfiguration.cs — remove the BeforeContainer option (field, ctor
  assignment, default initializer, property). Document the Pester.BeforeContainer.ps1 convention
  on the RepoRoot option so it stays discoverable. about_PesterConfiguration help regenerated.
• src/functions/Pester.Parallel.ps1 — Resolve-PesterBeforeContainer now resolves only the
  convention file; drop the worker-config sanitation line for the removed option.
• src/Main.ps1, src/Pester.Runtime.ps1 — comment updates.
• Tests — replace the explicit-option cases in Pester.RSpec.Parallel.ts.ps1 with a
  multi-file parallel example that shares one bootstrap via the stable $PSScriptRoot; rework the
  Pester crashes due to native command output in BeforeAll #2655 stray-output test in Pester.RSpec.ts.ps1 to use a convention file instead of the option.

Verification

• ./build.ps1 -Clean — succeeds; about-help regenerated without the option.
• P-tests: Pester.RSpec.Parallel.ts.ps1 (20/0) and Pester.RSpec.ts.ps1 pass.
• PesterConfiguration.Tests.ps1 (23/0) — format-data view stays in sync after removing the option.
• Invoke-ScriptAnalyzer with the custom build rules — no new findings in the changed files.

Fix #2838

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[nohwnd]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).