docs: add low-effort contribution examples guide (#497)

[Terryodib]

Summary

Adds docs/low-effort-contribution-examples.md, a worked-examples guide that documents the concrete shapes low-effort contributions take in PocketPay Mobile. For each category it shows a realistic poor example, explains why it falls short of the evaluation bar, and gives an improved alternative for the same work.

The guide is the worked-example companion to the Meaningful Change Guide (which lists these shapes in brief) — it cross-links rather than duplicates, and reuses the repo's existing checklists and catalogues as the standard each improved example is measured against.

Closes #497

Changes

• docs/low-effort-contribution-examples.md — new guide covering four categories, each as poor example → why insufficient → improved alternative:
  1. Superficial changes — restyling the Send-screen error banner vs. adding real over-balance validation wired to the submit button.
  2. Partial implementations — hardcoding every Vault lock as "Locked" vs. rendering all locked/matured/withdrawn states (plus disclosed-scope guidance).
  3. Missing tests — a "Copy Address" button with no test vs. happy-path and clipboard-failure tests plus a Screen Test Matrix update.
  4. Failing CI — opening a PR with red checks called "unrelated" vs. running the checks locally and substantiating any pre-existing failure.
• README.md — links the new guide from the Documentation section.

Acceptance criteria

• (a) Low-effort / superficial change examples documented — Section 1
• (b) Partial-implementation examples included — Section 2
• (c) Missing-test examples included — Section 3
• (d) Failing-CI examples included — Section 4
• (e) Improved alternatives shown — every section ends with an "Improved alternative"
• (f) README links to the examples — added to the Documentation section

Notes

Documentation-only change; no application code is touched, so no tests, screenshots, or CI-affecting logic apply. All examples cross-link existing docs (Meaningful Change Guide, Self-Review Checklist, Test-First Contribution Guide, UI State Catalogue, Accessibility Checklist, and the two readiness checklists) to stay consistent with the repo's house style.