UX Friction: Drop legacy "v1" enforcement by supporting .pss, .pwsh, or extension-less scripts (Related to #26584)

Start at the pwsh -File entry point and review the extension-less script handling discussed in related issue #26584. Define acceptance criteria for .pss, .pwsh, and extension-less files while preserving existing .ps1 support; the issue does not name specific files or tests.

Summary of the new feature / enhancement

Summary of the new feature/enhancement

The enforcement of the .ps1 file extension feels increasingly like an archaic holdover from the 2006 Windows-only PowerShell 1.0 architecture. Forcinig a hardcoded "Version 1" into the extension creates a persistent UX friction point for modern cross-platform automation pipelines.

Modern shells (such as Bash and Python) focus on script parsing logic rather than strict extension requirements. We need a cleaner alternative to .ps1 that adapts to modern cross-platform development workflows.

This is fundamentally related to the issue discussed in #26584 regarding extension-less script handling.

Proposed technical behavior

Allow the pwsh engine to execute files using modernized or non-enforced file parameters. I propose the engine should actively support the following three avenues:

1. Option A: Compact Script Extension (.pss)
   Support .pss ([P]ower[S]hell [S]cript) to offer a clean 3-character alternative that avoids system conflicts with Adobe PostScript (.ps).

2. Option B: Modernized Extension (.pwsh)
   Natively recognize .pwsh to align with the name of the open-source cross-platform engine binary. It drops the legacy version "1" while clearly differentiating Core from Windows PowerShell.

3. Option C: Pure Extension-less Execution (No Extension)
   Allow pwsh -File <filename> to parse and execute valid PowerShell script data regardless of the file suffix (or complete lack of one). This natively fixes environments like Linux Git hooks, which explicitly require extension-less scripts (see context in #26584).

Proposed solutions for compatibility

• Parser Agnosticism: If a text file is explicitly fed to the -File parameter, the engine should parse the text block rather than strictly demanding a .ps1 regex match.
• Side-by-Side Coexistence: Maintain full fallback support for .ps1 to prevent breaking millions of existing production enterprise scripts, while allowing developers to opt-into the cleaner naming styles.

Evaluation of alternatives

The alternative is forcing developers to write awkward wrapper scripts or manage complex execution blocks just to run an extension-less automation task. Adopting a flexible model simplifies the user experience and updates PowerShell's identity to better match the standards of the open-source community.

Proposed technical implementation details (optional)

No response