📖 [Docs]: Process-PSModule runtime settings contract documentation updated (#56)

Process-PSModule documentation now describes the current internal
runtime settings contract in evergreen terms while keeping
`.github/PSModule.yml` as the user-facing configuration source.

## Changed: Pipeline stages runtime contract documentation
- Clarified that Plan enriches `.github/PSModule.yml` into an internal
runtime `Settings` object shared between jobs.
- Documented the current phase-owned execution flags, test suite matrix
locations, and publish resolution paths as the active contract.

## Changed: Runtime settings reference style
- Replaced comparison-oriented wording with definitive runtime path
documentation (`Settings.*`) and behavior-focused descriptions.
- Kept version stamping and release-decision references aligned with
`Settings.Publish.Module.Resolution.*`.

## Changed: Usage behavior wording
- Updated the important-file behavior section to state the current
runtime values declaratively.

## Technical Details
- Files updated:
  - `src/docs/Frameworks/Process-PSModule/pipeline-stages.md`
  - `src/docs/Frameworks/Process-PSModule/usage.md`
  - `src/docs/Frameworks/Process-PSModule/configuration.md`
- Change is documentation-only and aligned with the current
Process-PSModule runtime contract.

<details>
<summary>Related links</summary>

- Upstream runtime contract context:
PSModule/Process-PSModule#402

</details>

---------

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

Author: MariusStorhaug

src/docs/Frameworks/Process-PSModule/configuration.md

@@ -8,6 +8,11 @@ description: The Process-PSModule settings file — every available setting, the
 The workflow is configured using a settings file in the module repository.
 The file can be a `JSON`, `YAML`, or `PSD1` file. By default, it will look for `.github/PSModule.yml`.
 
+The settings listed on this page are the user-facing configuration contract in `.github/PSModule.yml`. During the
+Plan phase, Process-PSModule enriches this input into an internal runtime `Settings` object that downstream workflows
+consume. Internal runtime paths in workflow docs (for example, `Settings.Publish.Module.Resolution.*`) describe that
+enriched inter-workflow contract, not a different authoring format for repository settings files.
+
 The following settings are available in the settings file:
 
 | Name                                      | Type      | Description                                                                                                                                                          | Default             |

src/docs/Frameworks/Process-PSModule/pipeline-stages.md

@@ -15,8 +15,36 @@ implements it.
 
 The Plan job is the single decision point of the workflow. It reads the settings file (`.github/PSModule.yml`),
 collects event context from GitHub, and decides what should happen in the rest of the process. Using that
-situational awareness, it calculates the next module version. All decisions are captured in a single `Settings`
-object — including version data under `Settings.Module` — that every downstream job receives.
+situational awareness, it calculates the next module version.
+
+The user-facing settings file stays in `.github/PSModule.yml`. The workflow enriches that input into an internal runtime
+`Settings` object passed between jobs. In this runtime contract, execution decisions are phase-owned (`*.Enabled`), test
+suite matrices are defined under each owning test phase, and resolved version metadata is stored under
+`Settings.Publish.Module.Resolution`.
+
+### Internal runtime settings contract
+
+| Runtime path | Meaning |
+| --- | --- |
+| `Settings.Linter.Repository.Enabled` | Whether repository linting runs. |
+| `Settings.Build.Module.Enabled` | Whether module build runs. |
+| `Settings.Test.SourceCode.Enabled` | Whether source-code tests run. |
+| `Settings.Test.PSModule.Enabled` | Whether framework tests run. |
+| `Settings.Test.Module.BeforeAllEnabled` | Whether setup scripts run before module-local tests. |
+| `Settings.Test.Module.MainEnabled` | Whether module-local Pester tests run. |
+| `Settings.Test.Module.AfterAllEnabled` | Whether teardown scripts run after module-local tests. |
+| `Settings.Test.TestResults.Enabled` | Whether test results aggregation runs. |
+| `Settings.Test.CodeCoverage.Enabled` | Whether code coverage aggregation/enforcement runs. |
+| `Settings.Publish.Module.Enabled` | Whether module publication/release runs. |
+| `Settings.Publish.Site.Enabled` | Whether documentation publication runs. |
+| `Settings.Test.SourceCode.Suites` | Source-code test suite matrix. |
+| `Settings.Test.PSModule.Suites` | Framework test suite matrix. |
+| `Settings.Test.Module.Suites` | Module-local test suite matrix. |
+| `Settings.Publish.Module.Resolution.Version` | Resolved semantic version used for build and publish. |
+| `Settings.Publish.Module.Resolution.Prerelease` | Whether the resolved version is prerelease. |
+| `Settings.Publish.Module.Resolution.FullVersion` | Resolved full version string. |
+| `Settings.Publish.Module.Resolution.ReleaseType` | Resolved release classification for this run. |
+| `Settings.Publish.Module.Resolution.CreateRelease` | Whether this run creates a release. |
 
 ## Lint-Repository
 
@@ -26,7 +54,7 @@ object — including version data under `Settings.Module` — that every downstr
 
 [workflow](https://github.com/PSModule/Process-PSModule/blob/main/.github/workflows/Build-Module.yml)
 
-- Compiles the module source code into a PowerShell module, stamping the version from `Settings.Module` into the manifest.
+- Compiles the module source code into a PowerShell module, stamping the version from `Settings.Publish.Module.Resolution.Version` into the manifest.
 - Uploads the built artifact.
 
 ## Test source code

src/docs/Frameworks/Process-PSModule/usage.md

@@ -291,7 +291,7 @@ When a pull request does not contain changes to important files:
 
 1. A comment is automatically added to the PR listing the configured patterns and explaining why build/test stages are
    skipped
-2. `Settings.Module.ReleaseType` is set to `None` (and `Settings.Module.CreateRelease` is `false`)
+2. `Settings.Publish.Module.Resolution.ReleaseType` is `None` (and `Settings.Publish.Module.Resolution.CreateRelease` is `false`)
 3. Build, test, and publish stages are skipped
 4. The PR can still be merged for non-release changes (documentation updates, CI improvements, etc.)