Refactor version resolution logic into helper functions (#2)

## Summary

Refactor the action script by moving the version resolution workflow out
of `scripts/main.ps1` and into a dedicated `scripts/Helpers.psm1`
module.

This keeps `main.ps1` as a thin orchestrator and makes the individual
steps easier to read, compare, and validate.

## Changes

- extract action input parsing into `Read-ActionInput`
- extract publish settings parsing into `Get-PublishConfiguration`
- extract pull request event loading into `Get-GitHubPullRequest`
- extract release decision logic into `Resolve-ReleaseDecision`
- extract GitHub and PowerShell Gallery version lookups into dedicated
helpers
- extract next-version calculation and action output writing into
dedicated helpers
- update `scripts/main.ps1` to orchestrate the helper calls

## Notes

- Intended behavior is unchanged for the normal release/version
resolution path.
- Error handling now throws from helper functions instead of using
inline `Write-Error`/`exit` in `main.ps1`.

## Validation

- verified the refactor against `main` with `git diff
--function-context`
- verified both edited PowerShell files report no editor errors locally

Refactor version resolution logic into helper functions (#2)

## Summary

Refactor the action script by moving the version resolution workflow out
of `scripts/main.ps1` and into a dedicated `scripts/Helpers.psm1`
module.

This keeps `main.ps1` as a thin orchestrator and makes the individual
steps easier to read, compare, and validate.

## Changes

- extract action input parsing into `Read-ActionInput`
- extract publish settings parsing into `Get-PublishConfiguration`
- extract pull request event loading into `Get-GitHubPullRequest`
- extract release decision logic into `Resolve-ReleaseDecision`
- extract GitHub and PowerShell Gallery version lookups into dedicated
helpers
- extract next-version calculation and action output writing into
dedicated helpers
- update `scripts/main.ps1` to orchestrate the helper calls

## Notes

- Intended behavior is unchanged for the normal release/version
resolution path.
- Error handling now throws from helper functions instead of using
inline `Write-Error`/`exit` in `main.ps1`.

## Validation

- verified the refactor against `main` with `git diff
--function-context`
- verified both edited PowerShell files report no editor errors locally

Refactor version resolution logic into helper functions (#2)

## Summary

Refactor the action script by moving the version resolution workflow out
of `scripts/main.ps1` and into a dedicated `scripts/Helpers.psm1`
module.

This keeps `main.ps1` as a thin orchestrator and makes the individual
steps easier to read, compare, and validate.

## Changes

- extract action input parsing into `Read-ActionInput`
- extract publish settings parsing into `Get-PublishConfiguration`
- extract pull request event loading into `Get-GitHubPullRequest`
- extract release decision logic into `Resolve-ReleaseDecision`
- extract GitHub and PowerShell Gallery version lookups into dedicated
helpers
- extract next-version calculation and action output writing into
dedicated helpers
- update `scripts/main.ps1` to orchestrate the helper calls

## Notes

- Intended behavior is unchanged for the normal release/version
resolution path.
- Error handling now throws from helper functions instead of using
inline `Write-Error`/`exit` in `main.ps1`.

## Validation

- verified the refactor against `main` with `git diff
--function-context`
- verified both edited PowerShell files report no editor errors locally

🌟 [Major]: Module version resolution now available as a standalone ac…

…tion (#1)

Module version resolution is now available as a standalone action.
Workflows can call it before building so the resolved version is stamped
into the artifact at build time, making the bytes that are tested the
bytes that ship.

- Resolves PSModule/Process-PSModule#326

## New: Standalone `Resolve-PSModuleVersion` action

The action consumes the JSON `Settings` output from
[`PSModule/Get-PSModuleSettings`](https://github.com/PSModule/Get-PSModuleSettings)
and emits:

| Output | Description |
| --- | --- |
| `Version` | `Major.Minor.Patch` portion of the resolved version. |
| `Prerelease` | Prerelease tag, empty when not a prerelease. |
| `FullVersion` | Full version string including `VersionPrefix` and
prerelease tag. |
| `ReleaseType` | `Release`, `Prerelease`, or `None` when no version
bump label is present. |
| `CreateRelease` | `true` when a release or prerelease should be
created. |

Typical usage in the Plan job:

```yaml
- name: Resolve module version
  id: resolve
  uses: PSModule/Resolve-PSModuleVersion@v1
  env:
    GH_TOKEN: ${{ github.token }}
  with:
    Settings: ${{ steps.settings.outputs.Settings }}

- name: Build module
  uses: PSModule/Build-PSModule@v5
  with:
    Version: ${{ steps.resolve.outputs.Version }}
    Prerelease: ${{ steps.resolve.outputs.Prerelease }}
```

The action validates `Settings.Publish.Module.ReleaseType`, applies
`IgnoreLabels` overrides, picks the bump type from PR labels
(`MajorLabels` > `MinorLabels` > `PatchLabels` / `AutoPatching`), then
computes the next version from the higher of the latest GitHub Release
and the latest PowerShell Gallery version. For prereleases it appends
the sanitized branch name, optional `DatePrereleaseFormat` timestamp,
and an incremental counter calculated from existing prereleases on the
same baseline + branch.

## Technical Details

- `action.yml`: composite action with inputs `Settings` (required JSON),
`Name`, `WorkingDirectory`, `Debug`, `Verbose`, `Version`, `Prerelease`,
plus `EventPath` and `EventJson` (both optional, for test overrides —
`EventJson` takes precedence over reading the file at `EventPath`). All
`${{ }}` template expressions are isolated in `env:` sections per zizmor
template-injection requirements. Installs
`PSModule/Install-PSModuleHelpers` and `PSSemVer` before running the
script.
- `scripts/main.ps1`: ports the version-resolution logic that previously
lived in `Publish-PSModule/src/init.ps1`. Reads configuration from
`PSMODULE_RESOLVE_PSMODULEVERSION_INPUT_Settings` JSON instead of
separate env vars. Reads the PR event from
`PSMODULE_RESOLVE_PSMODULEVERSION_INPUT_EventJson` when set, falling
back to the file at `GITHUB_EVENT_PATH`. Emits outputs via
`$env:GITHUB_OUTPUT`. Cleanup-tag discovery stays in
`Publish-PSModule/cleanup.ps1` and is intentionally out of scope here.
- `.github/workflows/Action-Test.yml`: 6 test jobs covering patch,
minor, major, auto-patch, ignore-label, and None scenarios. The
ignore-label job passes the fake PR event as a JSON string via
`EventJson` to bypass the runner's real event file, which cannot be
reliably overridden at the file-system level.
- `README.md`: replaces the template scaffold with the action's contract
and usage examples.

**Implementation plan progress** (PSModule/Process-PSModule#326):
- ✅ Create `Resolve-PSModuleVersion` (LICENSE, README, `action.yml`,
`scripts/main.ps1`, Action-Test workflow)
- ✅ Inputs: `Settings`, `Name`, `WorkingDirectory` (plus
`EventPath`/`EventJson` for test overrides)
- ✅ Outputs: `Version`, `Prerelease`, `FullVersion`, `ReleaseType`,
`CreateRelease`
- ✅ Port version-resolution logic from `Publish-PSModule/src/init.ps1`
(PSSemVer install, GitHub Releases query, PSGallery query, PR-label
parsing, bump selection, prerelease sequencing, `DatePrereleaseFormat`,
`VersionPrefix`)
- ⬜ Dedicated Pester unit tests for label parsing, bump selection, and
prerelease sequencing — covered by the six integration test jobs; a
focused unit-test suite remains open

Related PRs:
- PSModule/Process-PSModule#342 — rewires the workflow's Plan → Build →
Test → Publish chain to consume the resolved version.
- PSModule/Build-PSModule#136 — accepts `Version` / `Prerelease` inputs
and stamps them into the manifest at build time.
- PSModule/Publish-PSModule#71 — removes the version-calculation logic
that moved here.