Data Model — 094 Assignment Operations Observability Hardening

This feature introduces no new entities. It strengthens how existing operational artifacts are created, deduplicated, and displayed.

Entities (existing)

Represents a single observable operation for Monitoring.

Ownership:
- workspace_id required.
- tenant_id present for tenant-bound runs.
Key fields:
- type: operation type identifier (string).
- status: queued/running/completed.
- outcome: pending/succeeded/failed/etc.
- run_identity_hash: stable identity used for active-run dedupe.
- context: structured details for Monitoring (inputs, progress, counters).
- failures: array of failure items with stable code, normalized reason_code, and sanitized message.
- Counter-like fields may be stored in context depending on existing conventions.

Immutable audit record for security/ops-relevant mutations.

Scope invariant: if tenant_id is present, workspace_id must also be present.
This spec requires exactly one audit entry per assignment restore execution.

Represents a restore execution request and its lifecycle. Assignment restores are performed under an existing restore run.

Represents an item within a backup set; assignment fetch/enrichment is performed for a specific backup item.

One tenant has many operation runs.
One restore run should be associated with one or more operation runs depending on orchestration; this spec requires that assignment restore execution is observable via at least one operation run.
One backup item can have a related fetch/enrichment operation run.