feat(audio): remember speakers from diarization

[mudler-agent]

Description

Remember speakers from arbitrary multi-speaker recordings without preparing
separate clean enrollment clips. Diarization exports one profile per usable
speaker, and users preview clean speech before explicitly naming and saving it.

Follow-up to #12382 and mudler/parakeet.cpp#79; no issue-closing claim.
Dependency: mudler/parakeet.cpp#80 is merged.
The backend pins the merged native commit
bee7c14dfcc23613df58176c59a40459e7b47095.

• Add opt-in include_speaker_profiles to diarization and transport the
  versioned profiles through the parakeet backend. Normal responses stay
  unchanged. Unsupported profile export fails explicitly rather than
  silently falling back.
• Extend the existing /v1/voice/register endpoint for explicit profile
  enrollment while preserving audio enrollment. Validate profiles against
  identity and dimension supplied by the trusted loaded encoder, not the
  caller. Exact GGUF bytes determine encoder identity.
• Use one profile-capable diarization for slots, clean spans, and names;
  assign timestamped ASR words without a second diarization. Associate
  profiles by raw speaker slot, including zero and sparse slots, never by
  display order or name.
• Add a Diarization page in Studio with clean-interval previews and a
  “Name and remember” action. Relabel only after successful enrollment,
  reject stale results after recording/model changes, and keep independent
  registration IDs even when display names match.
• Require voice-recognition permission for export/enrollment alongside
  existing diarization and model-access checks. Exclude diarization and
  registration exchanges before API trace body capture, including the
  diarization alias and JSON audio. This flow does not persist vectors or
  recordings in browser storage.
• Update user documentation and Swagger artifacts.

Notes for Reviewers

Verification

The recorded focused Go suites pass. With protobuf tooling installed, run
from the repository root:

make protogen-go
GOMAXPROCS=2 go test -count=1 -p 2 \
  ./pkg/grpc/proto \
  ./core/schema \
  ./core/services/voicerecognition \
  ./core/backend \
  ./backend/go/parakeet-cpp \
  ./core/http/endpoints/localai \
  ./core/http/auth \
  ./core/http/middleware

Coverage includes profile validation, trusted encoder compatibility,
permissions, raw-slot mapping, duplicate-name registrations, and trace
privacy. These tests use synthetic data or mocked inference.

The UI production build passes under Node 22. The focused Playwright
suite passes 10 tests, with mocked API responses, not real inference.
To reproduce with Chromium installed, use two terminals:

# Terminal 1, using Node 22
cd core/http/react-ui
npm ci
npm run build
npm run dev -- --port 8089

# Terminal 2
cd core/http/react-ui
PLAYWRIGHT_EXTERNAL_SERVER=1 PW_WORKERS=1 \
  npx playwright test e2e/diarization-profiles.spec.js --project=chromium

Swagger JSON, YAML, and docs.go paths/definitions were checked for semantic
consistency. Generator execution was blocked by a missing go.sum
dependency; this is not a successful regeneration claim.

Limitations and compatibility

• The existing voice registry is global and ephemeral per process, not
  per-user durable storage. Registrations disappear on restart and are not
  synchronized across independent frontends.
• Profiles are sensitive, unsigned biometric data, not proof of identity
  or consent. Enrollment remains explicit; exporting never registers anyone.
• Real-model end-to-end enrollment/recognition, listening checks, and
  visual inspection remain unverified. No full make build or full test
  suite success is claimed.
• Native verification reports four passing tests and four model-dependent
  skips. See the dependency PR for its CMake/CTest reproduction commands.
• Existing UI lint/style debt remains unchanged; this is not a claim that
  the entire UI passes lint. The production build retains chunk-size warnings.
• Existing opt-out API behavior remains compatible. The new export workflow
  requires the pinned native symbols and a configured speaker encoder.

Signed commits

• Yes, I signed my commits.
• Documentation updated (docs/content/) for user-facing changes, or not applicable

The commits are not cryptographically signed; the checkbox remains unchecked.