feat: add approved VikingDB knowledge service

[YangYuS8]

What changed

• define a Provider-side approved-knowledge contract with explicit tenant, approval, source, version, effective-time, expiry, and score fields
• use the official Eino VikingDB Retriever as a reference backend
• push tenant and approval_status=approved filters into VikingDB
• validate tenant, approval, freshness, provenance, score, and duplicates again after retrieval
• add a service-level score floor that callers cannot lower
• add a private loopback-first nivora-knowledge HTTP service with independent authentication
• add a black-box nivora-knowledge-eval JSONL benchmark for expected/forbidden sources and latency
• document the collection schema, publication workflow, revocation behavior, and Provider boundary
• add a hardened systemd unit and environment template

Security boundary

Nivora Core does not receive VikingDB credentials. The product Provider resolves the tenant from trusted customer context and calls the private knowledge service. Malformed, stale, draft, expired, cross-tenant, low-confidence, or incomplete results fail closed.

Validation

The final read-only CI passes:

• clean go mod tidy
• gofmt
• go vet ./...
• go test -race ./...
• go build -trimpath ./...

This validates Nivora, both evaluation CLIs, and the approved knowledge service binaries with the locked official VikingDB Retriever dependency.