Clarify helper visibility decision

Update the no-nested-functions rule to require explicitly deciding whether extracted functions are private internals or public API.

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

Author: MariusStorhaug

src/docs/Modules/Standards.md

@@ -42,7 +42,7 @@ Layout rules:
 - **One declaration per file.** Filename matches the declared symbol exactly, including casing.
 - **Group by domain.** Use resource or behaviour groups — not verb folders, not endpoint paths.
 - **Mirror public and private domains.** Public command under `src/functions/public/Projects/` has related private helpers under `src/functions/private/Projects/`.
-- **No nested functions.** Do not define helper functions inside other functions. Put helper logic in separate private function files under `src/functions/private/<Group>/`.
+- **No nested functions.** Do not define helper functions inside other functions. Extract helper logic to a separate function file and decide whether it belongs in `src/functions/private/<Group>/` (internal-only) or `src/functions/public/<Group>/` (part of the module API).
 - **Declare dependencies where they are used.** Use `#Requires -Modules <Name>` at the top of each function file that needs an external module. Do not add `RequiredModules` to `src/manifest.psd1` — the build collects all `#Requires` declarations automatically and writes them into the compiled manifest. Entries in `src/manifest.psd1` are silently ignored for this purpose.
 - **Group documentation pages with source.** Place a `<Group>.md` file alongside the function files in each `src/functions/public/<Group>/` folder to provide a category overview in generated documentation.