Update and restructure QA local setup guide

[ptrcja]

Description

Following docs/qa_local_setup.md for the first time as a new contributor, I ran into several steps that didn't behave as documented. @nora-weisser and I agreed it was worth improving while the problems were fresh, so I worked through the whole guide against a running stack and updated everything that didn't match. I went through it twice, the second
time starting from a completely empty database.

The aim is that someone setting up the backend for the first time can follow it start to
finish without getting stuck, and knows what to do when something looks broken but isn't.

There are two kinds of change here: fixes, all reproduced locally, and a restructure,
which is more of a suggestion than a conclusion.

Corrected

Three things the guide described, which don't work that way:

The guide said	What actually happens
Log in as mentor@wcc.dev, then call GET /api/platform/v1/mentors	Fails twice — 401 without an API key, then 403 Role denied, because mentors can't call that endpoint. Now uses admin@wcc.dev and sends both headers.
Four seed log lines on startup	Five on a first run, and every restart after that shows Reset seeded user credentials instead — which reads like a warning but means the seed worked.
A seed config example without enabled: true	Copying it reproduces the bug fixed in #693, leaving no usable accounts.

Newly documented

Three things that weren't covered, and each cost me time:

• GET /api/cms/v1/mentorship/mentors returns 200 with an empty mentor list until a
  MENTORS page exists — the static fallback never fills mentors in. This looks exactly like
  a broken seed. Now explained, with the fix.
• Creating a page needs ADMIN or LEADER, and returns 409 if the page already exists
  (which it will, on any database that's been used before).
• Swagger's Authorize dialog has two fields, apiKey and bearerAuth, and neither is
  pre-filled — so it's easy to authorize and still get 401.

Restructure

Two changes to how the guide is organised, both open to discussion:

Swagger UI is now the main path, with curl kept as reference. The guide used curl
throughout. Given the audience is QA, Swagger seemed a better default — nothing to escape,
requests visible on screen, credentials entered once. Every curl example is still there,
under Reference.

Reference material grouped after the walkthrough. The steps now run start to finish
without interruption, and auth rules, seeding internals, seed config and troubleshooting sit
together below a divider.

Both are layout changes only, so they're easy to adjust if a different arrangement works
better.

Also included

• admin-wcc-app/README.md — the admin portal had no README, and the guide now links to
  it. It documents the NEXT_PUBLIC_API_KEY trap: .env.example ships it empty, and because
  the login endpoint doesn't need it, login succeeds and then every screen returns 401.
• Apple Silicon section cut back to the part that still applies — the MailHog platform
  warning, which is harmless.
• Troubleshooting extended with the errors hit along the way, and admin portal issues moved
  out to the portal's own README so each document covers its own area.

Notes

A few things came up that are worth fixing separately, rather than in this PR:

• Seeding the mentors page in the QA Docker stack would close bug: Mentor's page silently returns incorrect data (empty list of mentors) if the mentor's page is missing #654 and let us delete a whole
  section of this guide.
• admin-wcc-app/.env.example could default to NEXT_PUBLIC_API_KEY=local.
• Mentorship cycles can only be reopened with raw SQL — there's no endpoint for it.

Happy to split this up if it's easier to review in pieces.

Related Issue

Related but not closed by this PR: #654, which is the reason the "Making the mentor list work" section needs to exist at all.

Change Type

• Bug Fix
• New Feature
• Code Refactor
• Documentation
• Test
• Other

Pull request checklist

Please check if your PR fulfills the following requirements:

• I checked and followed the contributor guide
• I have tested my changes locally.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[nora-weisser]

Great job! 🚀