Share one overlay entity per config name and capture Live config baselines

Problem/Motivation

Editing the same config object in different workspaces creates a separate workspace_config entity per workspace. Nothing ties those entities together, and the default revision of each one keeps whatever Live held when that workspace first touched the config. After Live changes (a config import, another workspace publishing), reverting a published workspace with wse restores a stale copy of Live instead of the state Live had at publish time.

Proposed resolution

• Use one shared workspace_config entity per (config name, collection). Its default revision holds the Live baseline, and each workspace hangs its own pending revision off it through the workspace association.
• Refresh the Live baseline by appending a new default revision whenever a workspace adopts an existing entity, and again right before publishing (ahead of wse's revert snapshot), so a revert always restores Live-as-of-publish.
• Detect drift instead of blocking it: when Live changed after staging or after publishing, log a warning naming the affected configs; publishing and reverting still overwrite Live.
• Never delete overlay entities, only a workspace's own revisions and association rows, because wse's published-revision snapshots reference historical revisions as restore points.
• Split the oversized storage decorator: WorkspaceConfigDatabaseStorage keeps the StorageInterface facade and write guards, WorkspaceConfigOverlay owns the overlay entity lifecycle, and WorkspaceConfigRepository serves the read hot paths with straight SQL queries, off the entity load path.