[P1][Post-0.5][Full C] Define workspace-node generations, placement classes, and compatibility migration

[mightnent]

Parent epic: #82

Outcome

Extend the accepted C-minus workspace-node records into a forward-compatible Full C desired-state model without changing existing logical node IDs, tenant defaults, workspace owners, or verified-purge history.

Execution

• Priority: P1 post-0.5 Full C foundation.
• Deployment profiles: Hosted implementation required; customer-managed single-node compatibility required.
• Worktree boundary: Workspace-store schema, migrations, compatibility checks, store APIs, and focused database tests. Avoid scheduling, cloud provisioning, node transport, and product UI.

Scope

• Model shared-pool versus dedicated-tenant placement explicitly.
• Add logical-node generation and fencing state without coupling logical identity to a cloud instance.
• Store infrastructure attachment metadata separately from logical node identity.
• Add desired/observed lifecycle fields, compatibility/version fields, reconciliation timestamps, and the durable records required by capacity reservations and provisioning attempts.
• Preserve existing C-minus registrations, tenant assignments, workspace owners, audit records, and purge receipts through expand/migrate/contract rollout.
• Define a mixed-version compatibility window in which old and new services fail safely.

Non-goals

• Node bootstrap or credential issuance.
• Heartbeats, scheduling, reservations, reconciliation workers, or cloud resource creation.
• Drain, storage transfer, or workspace migration.
• Operator UI.

Definition of success

• Migrations are forward-only, transactional, checksummed, dependency-ordered, and safe to retry through the explicit migration job.
• Existing C-minus logical nodes, tenant defaults, workspace owners, audit records, and purge receipts remain unchanged and operator-visible.
• Placement class, node generation, infrastructure attachment, desired/observed state, compatibility, reservations, and provisioning attempts have tenant-safe database contracts.
• Mixed-version reads and writes are documented and tested; incompatible versions fail closed.
• Customer-managed single-node installations require no fleet provisioner.
• Focused store tests, npm run verify:db, and npm run verify:quick pass on the exact candidate SHA.