Templates tab persistence

[bph]

Part of #836. Wires the Templates tab. Depends on the Color/foundation PR. Final per-tab PR if scheduled last; can also land before others — order among PRs 2–5 is flexible.

Scope

• TemplatePartsPanel → top-level templateParts array.
• CustomTemplatesPanel → top-level customTemplates array (each entry: { name, title, postTypes: [...] }).
• Update readme.txt to document the Edit Theme Settings feature (if this PR lands last; otherwise the readme update goes with whichever per-tab PR completes the feature).

Acceptance criteria

• Adding / removing / editing template parts persists.
• Adding a custom template with multiple post types persists with the array intact.
• Removing a template removes the entry only (does not touch template files on disk — that's a separate concern).
• If this is the last per-tab PR: readme.txt describes the feature in the Description and Changelog sections.

Out of scope

• Touching template files on disk when entries are removed.
• WP-CLI.

References

• Tracking issue: [Tracking] Edit Theme Settings: phased implementation #836

[bph]

UX consideration discovered while smoke-testing the endpoint

WordPress only surfaces a customTemplates entry in the post/page editor's Template dropdown if a corresponding templates/<name>.html file exists in the active theme. Registering an entry in theme.json without the file is a silent no-op for the user — the entry is persisted but invisible.

Confirmed via smoke test against #837: the endpoint correctly wrote customTemplates: [{name: "page-wide", ...}] to theme.json, but the dropdown didn't show the option because templates/page-wide.html didn't exist.

This affects how this PR should handle the Custom Templates UI. Three options:

1. Warn-only — let users register entries freely; show an inline warning when there's no matching file ("create templates/<name>.html in the Site Editor to make this template selectable"). Non-destructive, transparent.
2. Filter the picker — only list templates whose file already exists. Cleaner, but blocks the "register first, create file second" workflow.
3. Auto-stub the file — also create an empty templates/<name>.html on save. Forces existence; risks creating files the user didn't intend.

Recommendation for v1: Option 1 (warn-only). Consistent with the modal's role as a settings editor (not a file generator), and matches how we expect users to flow between the Site Editor (file creation) and Edit Theme Settings (registration metadata).

Worth surfacing in the help text on the Custom Templates panel so this isn't a surprise.