📖 [Docs]: Functions guide states that .INPUTS/.OUTPUTS descriptions are required (#81)

The `.INPUTS`/`.OUTPUTS` section of the Functions coding standard showed
the correct blank-line format but never stated that a description is
**mandatory**. Readers — and agents generating comment-based help —
could reasonably assume the type name alone is sufficient.

## Changed: Description requirement made explicit

A new first rule is added to the `### .INPUTS and .OUTPUTS` bullet list
making clear that every entry must include a description that says what
is actually piped in (`.INPUTS`) or returned (`.OUTPUTS`) in plain
language — not just a restatement of the type name.

## Technical Details

- Single bullet inserted as the first item in the rules list at the
bottom of the `### .INPUTS and .OUTPUTS` sub-section in
`src/docs/Coding-Standards/PowerShell/Functions.md`.
- No other content restructured.

<details>
<summary>Related issues</summary>

- Fixes #80

</details>

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

Author: MariusStorhaug

src/docs/Coding-Standards/PowerShell/Functions.md

@@ -146,6 +146,7 @@ The user record for the requested id.
 
 Rules that apply to both sections:
 
+- **Include a description for every entry** — the type name alone is not sufficient. The description should say what is actually piped in (for `.INPUTS`) or what is returned (for `.OUTPUTS`) in plain language, not just restate the type name.
 - Use the fully-qualified .NET type name (`System.String`, `System.Management.Automation.PSCustomObject`), not a PowerShell type accelerator (`[string]`, `[pscustomobject]`).
 - When no parameters accept pipeline input, write `None` as the type with `You can't pipe objects to <CommandName>.` as the description paragraph (use the actual command name).
 - Repeat the keyword once per type when multiple types are accepted or returned.