Prevent staging the same new config name in multiple workspaces

Problem/Motivation

Config import matches by name. When two workspaces stage the same new name (one that does not exist in Live yet) with different data, publishing the second workspace silently overwrites what the first one published. This is easy to hit: two workspaces making unrelated field changes to the same never-customized bundle both create core.entity_form_display.* as a new name, and views, menus or node types collide the same way when editors pick the same machine name.

Proposed resolution

• Reject creating a config name in write() / rename() while another top-level workspace already stages it. Deleting the staged config frees the name again, and delete markers count as staging it.
• Add a ConfigWorkspaceConflict validation constraint to workspace-safe schema types, so #config_target forms and validating API clients get a violation instead of the storage exception. Config entity forms do not validate their schema on submit, so a #validate callback runs the constraint for new config entities.
• Re-check the rule when a workspace is published and stop the publish with a reason, which catches conflicts from concurrent writes that the write-time check cannot see.
• Add a WorkspaceConfigRepository service that answers "which top-level workspaces stage this name" with a direct query on the tracked config revisions.

Names that already exist in Live can still be overridden by several workspaces at once; that stays last-publish-wins and is out of scope here.