📖 [Docs]: PR descriptions now require standardized ending blocks (#95)

PR description guidance now requires a consistent ending section that
matches the standard currently used in PSModule/Domeneshop. Contributors
now get explicit, copy-pasteable structure for the separator line plus
both foldable blocks with exact summary text.

## Changed: PR ending structure is now explicitly required

The PR format standard now requires all PR descriptions to end with a
horizontal separator and two `<details>` blocks, in a fixed order and
with exact summary text.

---
<details>
<summary>Technical details</summary>

- Updated `Ways-of-Working/PR-Format` to require the exact
end-of-description structure.
- Replaced prior "Technical Details" heading guidance with required
foldable block guidance.
- Updated the example snippet to use `Technical details` and `Relevant
issues (or links)` exactly.

</details>

<details>
<summary>Relevant issues (or links)</summary>

- PSModule/Domeneshop#16

</details>

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

Author: MariusStorhaug

src/docs/Ways-of-Working/PR-Format.md

@@ -92,36 +92,38 @@ Under each header:
 
 Do **not** mention internal function names, class names, private APIs, or refactoring decisions here.
 
-### 3. Technical details (optional)
+### 3. Required ending blocks
 
-```markdown
-## Technical Details
-```
-
-For reviewers and maintainers. Not part of the release note. Include:
-
-- Which internal functions, classes, or files were changed.
-- Implementation approach and design decisions.
-- Backward compatibility notes for developers.
-- **Implementation plan progress** — cross-reference Section 3 of the linked issue. Which tasks does this PR complete? Which remain?
+At the very end of every PR description, use this exact structure:
 
-Omit the section entirely if there's nothing noteworthy.
+```markdown
+---
+<details>
+<summary>Technical details</summary>
 
-### 4. Related issues
+...
 
-A collapsible `<details>` block at the very end of the description containing issue links. Always use fully qualified references (`Owner/Repo#N`) so links work across repositories.
+</details>
 
-```markdown
 <details>
-<summary>Related issues</summary>
+<summary>Relevant issues (or links)</summary>
 
 - Fixes Owner/Repo#123
 - Owner/OtherRepo#124
 
 </details>
 ```
 
-One bullet per linked issue. Use a [closing keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue) (`Fixes`, `Closes`, `Resolves`) when the PR fully addresses the issue. Otherwise, list the reference without a keyword to indicate a relationship without auto-closing.
+The **Technical details** block is for reviewers and maintainers. Include internal implementation notes such as:
+
+- Which internal functions, classes, or files were changed.
+- Implementation approach and design decisions.
+- Backward compatibility notes for developers.
+- **Implementation plan progress** — cross-reference Section 3 of the linked issue. Which tasks does this PR complete? Which remain?
+
+The **Relevant issues (or links)** block is required and uses fully qualified references (`Owner/Repo#N`) so links work across repositories.
+
+Use one bullet per linked issue. Use a [closing keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue) (`Fixes`, `Closes`, `Resolves`) when the PR fully addresses the issue. Otherwise, list the reference without a keyword to indicate a relationship without auto-closing.
 
 If no issue is linked: **stop**. PRs without issues break the workflow. Route back to the Ideator role or proceed only on explicit user confirmation. The Shipper enforces this.
 
@@ -150,15 +152,19 @@ The `repo properties` command remains available if only the properties are neede
 
 Commands that query a specific repository, enterprise, or release by name now return nothing instead of throwing when the resource doesn't exist. This makes them safe to use in conditional logic without error handling.
 
-## Technical Details
+---
+<details>
+<summary>Technical details</summary>
 
 - The repository model's custom-properties field is now a typed collection rather than an untyped object.
 - The GraphQL query layer splits error handling into partial-success (data + errors → warnings) and full-failure (errors only → terminating error) branches.
 - Null guards added to the repository lookup helpers.
 - Implementation plan progress: tasks 1–3 in #218 completed; task 4 (integration tests) remains.
 
+</details>
+
 <details>
-<summary>Related issues</summary>
+<summary>Relevant issues (or links)</summary>
 
 - Fixes Owner/Repo#218
 - Owner/Repo#219