feat(admin): Phase 11 Module 7 — System Settings & Reports (mock data) — COMPLETES PHASE 11

13 pages: Settings (index redirect + general/seo/email/storage/search/
ai/security) and Reports (overview + content/users/localization/system).

Success criterion #1 (unified, extensible settings interface): a single
shared layout.tsx mounts SettingsNav once (not repeated per page); all
7 forms are built on the exact same SettingsSection/SettingsField/
SettingsSaveButton with zero per-section variants. Same pattern for
Reports (ReportsNav in a shared layout). Adding an 8th settings section
means one line in SettingsNav + one form + one page — no changes to
any existing page.

Success criterion #2 (reports derived, not duplicated): lib/mock/
reports.ts holds NO new data array. Every number is computed from
mockContentItems (Phase 9.5), academyLessons/courses (Phase 10),
mockMediaAssets (Module 4), mockAdminUsers/fullActivityLog (Module 5),
getAllLanguageStats/buildTranslationQueue (Module 6). The localization
report reuses CompletionCard (Module 6) verbatim — no parallel report-
only copy. System report's 'error log' is the real activity log
filtered by result=FAILURE, not a separate placeholder array (only
memory usage is an explicit, clearly-labeled placeholder, since no real
OS metric is obtainable in a frontend-only environment).

New: SimpleBarChart — a deliberate plain-CSS alternative to Chart.js
(available in the project but unused here), per the explicit
'avoid unnecessary complexity' instruction. StorageSettingsView shows
real usage for the 'Local' provider (derived from mockMediaAssets) and
honest zero usage for S3/Backblaze/R2 (not actually enabled), not
fabricated numbers.

DataTable/FilterCheckboxGroup/Pagination deliberately NOT used here —
settings are fixed-field forms and reports are aggregate views, neither
needs a sortable/filterable table; forcing them in would have been
reuse without genuine purpose (same reasoning as Module 4/5/6 status-
badge decisions).

Verified: lint, tsc, build all clean on first run; dev server actually
run and curled across 15 routes (13 new + settings index redirect +
an English sample) — all correct, with cross-module data (storage
providers, content counts, role distribution) confirmed in raw SSR
HTML. One transient curl 000 on the very first request to a brand-new
route was confirmed as Turbopack's first-compile warmup, not a bug,
by retrying with a longer timeout (same pattern documented in earlier
phases).

See docs/SYSTEM_SETTINGS_AND_REPORTS_REPORT.md for full details.

This completes Phase 11 (Enterprise Admin CMS) — 8 modules, 15+ admin
pages, one DataTable system serving 6 of them with zero modification.
