docs: consolidate documentation and archive temporary reports

Step 1-2 (audit + plan): classified 35 project markdown files into
Core/Architecture/ADR/Temporary-audit/Sprint-report/Generated-review/
Duplicate/Obsolete/Historical. Agent-tooling files (.agents/skills/**,
.superpowers/**, docs/context/**, CLAUDE.md/GEMINI.md/AGENTS.md/
.github/copilot-instructions.md) explicitly out of scope — intentional
per-tool duplication, not documentation debt.

Step 3 (merge, no information lost):
- docs/PROJECT.md -> docs/PROJECT_INDEX.md, rewritten as the single
  entry point: system overview, living-doc index, archive pointer,
  current status, and a critical-finding callout up top.
- docs/backend/BACKEND-INTEGRATION.md -> docs/BACKEND_API.md,
  docs/backend/REMAINING-BACKEND-WORK.md ->
  docs/BACKEND_API_REMAINING_WORK.md (also folded in a legitimate
  uncommitted status update that had been sitting unstaged all
  session: categories marked DONE, order-creation endpoint noted done).
- RELEASE-NOTES.md merged into CHANGELOG.md (was a near-duplicate of
  the same release content in friendlier prose), then deleted.
- KNOWN-ISSUES.md: added item 13 (see below) and item 14 (missing
  canDeactivate on admin/products edit, from the archived PROJECT-STATE
  audit, re-verified still true); added a correction note to Fixed
  item 7.
- All cross-references to renamed/moved files fixed across every
  kept doc (grep+sed pass, then verified with a link-existence check
  across all 58 in-scope markdown files -> 0 broken links).

Step 4 (archive, nothing deleted without merging first): created
docs/archive/, moved 19 files there (3 root sprint reports, 1 platform
report, SPRINT-PLAN.md, and 14 one-off audit/review/report docs).
Added correction headers to the 3 archived docs whose conclusions were
affected by the finding below, rather than silently leaving them
misleading.

Step 5: docs/PROJECT_INDEX.md rewritten per the mission brief -
someone opening the repo should understand the whole system from it.

IMPORTANT FINDING (surfaced during this audit, not the mission's
primary goal but too significant to bury): pages/category/*,
pages/search/*, pages/item-detail/*, pages/info/**, pages/legal/**
(40+ files) are entirely unrouted dead code - app.routes.ts's
cmsContentRoutes is a literal empty array, and category/search/product
routes redirect to CatalogContainerComponent/
ProductDetailsContainerComponent, not these files. Confirmed against
app.routes.ts directly and cross-checked against FRONTEND.md's own
routing description. This means several fixes from earlier this cycle
(RC-Premium-01, RC STORE-01) and the dead-code cleanup sprint's
conclusion that these files were live were all wrong - documented as
KNOWN-ISSUES.md item 13, flagged at the top of PROJECT_INDEX.md, and
noted on the 3 archived docs whose conclusions it affects. No
application code was changed to fix this (out of scope per this
session's 'documentation only' constraint) - it needs a wire-it-up-or-
delete-it decision first.

Verification: tsc --noEmit clean, npm run build green, all markdown
links across 58 in-scope files resolve (checked programmatically).
No application/Angular/backend code modified.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/AUTH.md

@@ -5,7 +5,7 @@ code that exists in `src/app/core/auth/` today, wired to endpoints that do
 not exist on the backend yet. No route currently requires this flow — the
 live admin gate remains the Telegram-QR-based `AdminAuthService` /
 `adminAuthGuard` (`src/app/core/admin-auth/`, documented in
-`docs/backend/BACKEND-INTEGRATION.md` §2.4–2.5). This module is the
+`docs/BACKEND_API.md` §2.4–2.5). This module is the
 integration target once the backend ships the endpoints below.
 
 Do not point any live route's `canActivate` at `ed25519AuthGuard` until the
@@ -14,7 +14,7 @@ before then would lock every admin out.
 
 ## 1. Why this exists
 
-`docs/backend/BACKEND-INTEGRATION.md` §2.5 documents the current system's
+`docs/BACKEND_API.md` §2.5 documents the current system's
 biggest security gap: admin and customer login hit the *same* Telegram
 session endpoint, so the backend has no way to distinguish an admin login
 attempt from a customer one at the moment of login — authorization is
@@ -153,7 +153,7 @@ This is deliberately coarse and mirrors the existing bootstrap-level
 `PermissionsConfig` shape (`src/app/shared/models/config/permissions.model.ts`).
 Finer-grained, per-domain permissions (e.g. "can edit prices but not delete
 products") stay server-side until a real permission model exists there —
-see `docs/backend/BACKEND-INTEGRATION.md` §"Admin-role-required". Use
+see `docs/BACKEND_API.md` §"Admin-role-required". Use
 `PermissionService.has(permission)` / `permissionGuard(permission)` to gate
 UI and routes; never treat a passing client-side check as authorization by
 itself.
@@ -250,7 +250,7 @@ collaborators reachable through it.
   implemented here.
 - **The frontend is not the authorization boundary.** Every admin
   request must be independently checked server-side against the caller's
-  actual role, exactly as `docs/backend/BACKEND-INTEGRATION.md` §2.5
+  actual role, exactly as `docs/BACKEND_API.md` §2.5
   already states for the Telegram flow. A decoded JWT claim or a passing
   `PermissionService.has()` check is UX, not proof.
 - **Refresh tokens should rotate.** Every `POST /refresh` response is