Give plugin field widgets the identity of the document they are editing

[DavidPivert]

Summary

Give plugin field widgets the identity of the document they are editing — the collection slug and the entry id — as part of FieldWidgetProps.

This is step (1) of the two-step split proposed by @kwmr in #2227, separated out because it is independent of the harder part. It does not need the reactive draft view, it does not touch layout or rendering, and it unblocks a concrete workaround that two of us are running in production today.

The problem

A field widget cannot tell which document it belongs to. FieldWidgetProps carries value, onChange, label, id, required, options, minimal — everything about the field, nothing about the entry.

Any widget that needs to call its own plugin route therefore has to recover the id from the URL:

const [, collection, id] = location.pathname.match(/\/_emdash\/admin\/content\/([^/]+)\/([^/]+)/) ?? [];

Two independent sites in #2227 are doing exactly this. It works until admin routing changes, at which point it breaks silently — the widget still renders, it just talks to the wrong document or none at all.

What it would take

Smaller than it looks, but not zero — I checked the 0.35 admin bundle rather than assuming:

• FieldRenderer currently receives name, field, value, onChange, onEditorReady, minimal, pluginBlocks, onBlockSidebarOpen, onBlockSidebarClose, manifest. No document identity.
• It has exactly one call site, inside ContentEditor — which already has collection and item in scope.

So: thread two values from an existing call site, forward them to the plugin component, extend the type. Plus tests, a changeset, and a docs line.

One naming trap worth settling first

FieldWidgetProps.id is already taken — it is the HTML id attribute for the input. Adding a second id meaning the entry would be a footgun for every widget author.

Two shapes that avoid it:

// A — flat, explicit
collection: string;
documentId: string | null;   // null while the entry has never been saved

// B — nested, room to grow
document: { collection: string; id: string | null };

I lean towards B: it keeps the document namespace separate from the field namespace, and gives somewhere obvious to put locale or status later without another round of flat additions. But A is smaller and I have no strong attachment — the important thing is that it isn't called id.

null rather than undefined for an unsaved entry, so a widget can distinguish "new document" from "prop not provided by an older host".

Why raise it separately

#2227 asks for a reactive read view of the in-editor draft, which is real design work. This piece isn't: it is additive, backward compatible, and useful on its own. Shipping it first removes the URL-parsing hack from every field widget in the wild, whatever eventually happens to the larger request.

Happy to open the PR if this is something you would take. We run EmDash on a production Workers site (paid plan, ~12 plugins, bilingual across 6 collections) and can test against real content.