feat(platform): complete finance content audit APIs

.superpowers/sdd/2026-07-27-platform-admin-full-audit/task-5-report.md

@@ -0,0 +1,26 @@
+# Task 5 implementation report
+
+## RED / GREEN
+
+- RED: `go test ./internal/logic/platform ./internal/routers -run 'Test(PlatformFinanceContentAndAuditRoutes|ApprovalValues)' -v` failed before implementation because Task 5 routes were absent and the approval update whitelist did not exist.
+- GREEN: the same route and approval-contract tests pass. A transactional approval test confirms the approval update only persists status, opinion, handler identity, and handling time, then inserts an `aud_operation_log` in the same transaction.
+
+## Changes
+
+- Registered writable, restricted-field finance APIs (`fin_payment`, `fin_settlement`, `fin_reconciliation`) and content/customer-service APIs (`cnt_content`, `ntf_template`, `cs_ticket`). They retain the standard status patch and logical archive behavior.
+- Registered wallet, report, and audit record resources as GET-only list/detail APIs. No generic write route is registered for those resources.
+- Added `POST /audit/aud_approval/:identity/approve`. It derives the handler identity from the authenticated JWT, records the handling timestamp, limits the update to the four approval fields, and appends before/after audit data atomically.
+- Extended `AudApproval` with persisted `handler_identity` and `handled_at` fields.
+- Added route, approval/audit-transaction, and empty-dashboard-zero-value coverage.
+
+## Verification
+
+- `gofmt -w internal/models/aud_approval.go internal/routers/platform.go internal/routers/platform_test.go internal/logic/platform/audit.go internal/logic/platform/audit_test.go internal/logic/platform/health_test.go` — PASS
+- `go test ./internal/logic/platform ./internal/routers -run 'Test(PlatformFinanceContentAndAuditRoutes|ApprovalValues|ApproveAuditOnlyUpdates|DashboardOverviewReturnsZero)' -v` — PASS
+- `go test ./...` — PASS
+- `go build ./cmd/main` — PASS
+- `git diff --check` — PASS
+
+## Concerns
+
+- Approval status values are accepted as non-empty strings to preserve the existing status model; a future workflow may want an explicit state-transition policy (for example, only `pending -> approved|rejected`).