docs: add rated engineering feature matrix for mpiper

[usehoplite]

Summary

Adds references/ENGINEERING_FEATURE_MATRIX.md, a rated roadmap of features that would take MPiper from a working demo pipeline to a production-grade engineering project. Each entry is scored on engineering value (correctness, reliability, security, testing, operability), not just product value, with priority and effort per row plus a 3-phase build order.

This is a documentation contribution only — no code changes.

What's in the matrix

• P0 foundations — latent defects found during code review that should be fixed before any feature work:
  • Schema drift between the embedded migrations the server auto-runs (internal/database/migrations/) and the documented manual schema (db/migrations/001_seed.sql) — embedded variants.image lacks variant_hash/params and embedded assets lacks width/height, both written by the worker.
  • CI "integration" job (ci.yml) runs go test -tags=integration but no test file carries that tag, so it executes zero tests.
  • tests/performance_suite_test.go fails go test ./... because it t.Fatals when PERF_TEST_URL is unset and has no build tag.
  • Auth is a self-made AES-GCM token with no identity model, issuance, expiry, or revocation.
• Rated, prioritized features across six pillars: reliability/correctness (outbox, dead-letter queue, webhook engine, GC), API surface (read/variants API, batch, real-time status, idempotency keys), security (users/RBAC, API keys, HMAC signing, signed GET), media pipeline (HLS/DASH, AVIF, libvips), observability (unified tracing, SLI/SLOs, alerting), and DX/testing (E2E pipeline test, OpenAPI, Helm/Terraform).
• A note on what the project already proves well (layered Go service, provider-agnostic storage, content-addressed dedup, Redis Streams consumer with retry/recovery, observability stack, CI/CD release tracks, k8s manifests).

Verification

• Documentation-only change; no code, tests, or build behavior affected.
• File committed as a single change; rendered markdown reviewed for correctness against the codebase it describes.

Risks / notes

• The P0 schema-drift and CI findings describe real defects; implementers should confirm them against the live deployment before acting, as the embedded vs. seed schema may already have diverged in practice.
• Some items in the matrix (outbox, webhook engine) overlap with in-flight branches (feat/dev-55-outbox-pattern, feat/webhook-notifications) — those are flagged in the doc as opportunities to adopt existing work rather than re-implement.