feat: expand web console with memory and artifact management

Feature description

Upgrade the web console from a read-only dashboard into a usable management UI for PowerContext.

Today the web console ships only two pages:

• Dashboard (src/powercontext/server/templates/pages/dashboard.html): scope picker, token-reduction estimate, Sources / Memory / Artifacts / Pending review counts, artifact family table, activity heatmap, recall trend.
• Handoff Report (src/powercontext/server/templates/pages/handoff_report.html): report editor.

Meanwhile the HTTP API (contracted in openapi/powercontext.yaml) already exposes far more capability than the UI surfaces:

• Memory entry list / get / revise / retire and the change audit log
• Memory search with auto / fts / vector / hybrid modes
• Artifact candidate review workflow: list / get / approve / reject / revise
• Experience / Skill get / propose / generate
• External skill scan / list / resolve / import
• Handoff lifecycle operations (prepare / finalize / commit / continue)

Proposed new pages

1. Memory management page

   • Browse entries per scope with filters by kind (decision / constraint / current-state / task-outcome / ...) and status (active / inactive), plus pagination
   • Entry detail view: content, citation, revision history
   • In-page revise and retire actions (with confirmation)
   • Change audit timeline (list memory changes)

2. Memory search page

   • Keyword search with mode selector (auto / fts / vector / hybrid) showing hits and relevance

3. Artifact review workbench

   • Candidate list filterable by family (experience / skill) and status (pending / approved / rejected)
   • Candidate detail with content preview; approve / reject / revise actions
   • Complements #1302 (review workflows with Agent targets)

4. Experience / Skill viewer

   • Entry point from candidate or family table to artifact detail; trigger to generate a Skill from an Experience

5. Handoff view

   • List prepared / committed handoffs with detail view and a continue entry point

Frontend UX improvements

• Consistent top navigation across pages with current-page highlight (current header.html serves only two pages)
• Shared loading / error / empty state components instead of per-page handling
• Uniform pagination parameters for all list views
• Full i18n coverage for new pages via the existing data-i18n mechanism (en/zh)
• Accessibility: semantic tables, aria labels on action buttons, keyboard reachability
• Basic mobile adaptation (the current dashboard layout breaks on small screens)

Problem and proposed solution

Users can only see aggregate statistics in the web console today; every real management action requires the CLI or raw API calls. This limits adoption of the server UI as the primary way to inspect and curate project memory.

Proposed solution: keep the build-step-free stack (server-rendered Jinja templates + vanilla ES modules), add the pages above as new routes in src/powercontext/server/web.py, and consume only endpoints already defined in openapi/powercontext.yaml. If any endpoint is missing, change the contract first, then run make api-generate && make contract-test.

Acceptance criteria:

• Memory entries can be browsed, searched, revised, and retired from the UI, matching API behavior
• Artifact candidates can go through approve / reject / revise entirely from the UI
• All new pages have complete en/zh translation keys
• Existing dashboard and handoff report behavior does not regress (make test, make contract-test pass)

Alternatives considered

• Introduce a lightweight frontend framework (e.g., Vite + Preact/Svelte): rejected for now to avoid adding a build toolchain to an otherwise Python-first repo; can be revisited if the console keeps growing.
• Ship only API improvements and rely on CLI: insufficient for users who want visual review of memory and artifact candidates.
• Real-time updates (WebSocket/SSE) for lists: out of scope; polling refresh is enough for v1.

Additional context

• Related: #1302 (Experience and Skill review workflows with Agent targets) — the review workbench is the human-side counterpart of that workflow.

• The generated HTTP clients under src/powercontext/http/_generated/ must not be edited by hand.

• Yes, I am willing to contribute code, docs, or design feedback.

Start with src/powercontext/server/web.py and the existing templates at src/powercontext/server/templates/pages/dashboard.html, handoff_report.html, and header.html. Read the contracts in openapi/powercontext.yaml before mapping the memory and artifact workflows, and do not edit generated clients. Done means the new management views and translations meet the listed acceptance criteria while make test and make contract-test pass.