feat: permissions CRUD browser integration + E2E enhancements

Backend:
- permission_handler: 完善权限 CRUD 接口（列表/创建/更新/删除）
- auth_handler: 修复认证处理逻辑
- router: 新增权限管理路由
- handler_test: 新增权限 handler 测试覆盖

Frontend:
- permissions.ts/test.ts: 权限服务层完整实现
- profile/settings/service_tests: 服务适配器修正
- client.ts: HTTP 客户端健壮性增强
- vite.config.js: 构建配置优化
- E2E 脚本: run-playwright-cdp-e2e 大幅增强（权限流程覆盖）

Docs:
- REAL_PROJECT_STATUS: 状态更新
- PRODUCTION_CHECKLIST/QUALITY_STANDARD/TECHNICAL_GUIDE/PROJECT_EXPERIENCE_SUMMARY: 团队规范完善
- plans/2026-04-23: 权限浏览器 CRUD 设计方案

验证: go build 0错误

docs/superpowers/specs/2026-04-23-permissions-browser-crud-design.md

@@ -0,0 +1,54 @@
+# Permissions Browser CRUD Design
+
+**Date:** 2026-04-23
+
+**Goal:** Extend the supported Playwright CDP browser gate so the admin `PermissionsPage` is covered by a real CRUD scenario instead of remaining outside the main browser acceptance path.
+
+## Scope
+
+- Add one new supported browser scenario: `permissions-management-crud`.
+- Cover real admin login, permissions page load, top-level permission creation, child permission creation, list/tree verification, edit, status toggle, and delete.
+- Reuse the existing supported runner `frontend/admin/scripts/run-playwright-cdp-e2e.mjs`.
+- Keep selector strategy aligned with current team rules: prefer route, heading, role, label, and scoped containers over broad text scans.
+
+## Non-Goals
+
+- No redesign of the permissions page UI.
+- No new backend permissions model behavior beyond what the existing page and APIs already expose.
+- No expansion into OS-level automation or unsupported browser tooling.
+
+## Approach
+
+- Treat the new browser scenario as the primary verification surface.
+- If the scenario exposes a product defect, add the smallest regression test needed in the affected frontend or backend area, then fix the product behavior.
+- If the scenario exposes only runner fragility, fix the runner instead of weakening assertions.
+
+## Required Browser Flow
+
+1. Log in as a real admin through the supported login surface.
+2. Open `/permissions` and verify the page heading renders.
+3. Create a new top-level permission through the page modal and wait for the real create API response.
+4. Create a child permission under that top-level node and wait for the real create API response.
+5. Switch to list view and verify the new permissions appear.
+6. Edit the top-level permission through the page modal and wait for the real update API response.
+7. Toggle the permission status through the page action and wait for the real status API response.
+8. Delete the child permission, then the top-level permission, each with real delete API responses.
+9. Verify the created records are gone from the visible page state.
+
+## Verification
+
+- Targeted red/green loop:
+  - `cd frontend/admin && $env:E2E_SCENARIOS='permissions-management-crud'; npm.cmd run e2e:full:win`
+- If product code changes:
+  - run affected frontend tests first
+  - then `cd frontend/admin && npm.cmd run test:run`
+  - then `cd frontend/admin && npm.cmd run lint`
+  - then `cd frontend/admin && npm.cmd run build`
+- Final acceptance:
+  - `go test ./... -count=1`
+  - `go vet ./...`
+  - `go build ./cmd/server`
+  - `cd frontend/admin && npm.cmd run test:run`
+  - `cd frontend/admin && npm.cmd run lint`
+  - `cd frontend/admin && npm.cmd run build`
+  - `cd frontend/admin && npm.cmd run e2e:full:win`