A change to a common list is refused — and turned into a way forward

403 vs 409 — the difference is whether you may fork

The service decides, in this order (design record D7): unreadable → 404; readable but not writable → 409 fork_required if you hold SelectionListCatalog:create, else 403. The UI branches on code + reason only — never on its own guess of your role.

Fail-closed rules

• A 409 without reason (key taken, last owner, …) is the ordinary conflict message from the 4.0.0 frames — the fork banner renders only for reason: fork_required.
• The Fork CTA uses source_list_id from the error body, not the id in the page URL — the 409 names the list the service refused.
• fork_url is relative (/v1/…) and is resolved against the same-origin API base. A body carrying an absolute URL is ignored and the client's own forkList(sourceListId) is used.
• The same ForkRequiredBanner renders wherever a mutation can be refused: the value editor, the reorder save, the list settings, the translation workbench and auto-fill. It sits next to the control that was refused, not in a global toast.
• The refusal never auto-forks. Forking creates a list in the organization and costs quota — it is always an explicit choice in the next dialog.
• Flag OFF: the service answers 4.0.0 behaviour and no common list is reachable, so this banner cannot appear; the UI does not render it even if a stray reason arrives.