Custom Records builder layout

Place module.dynamic-records parts beneath one workspace. A configured moduleKey uses that persisted module contract. When no module is configured, module-choice requires the user's explicit choice; it does not select the first module automatically.

The workspace exposes eyebrow, title, read-only-note, new-action, refresh-action, module-choice, module-empty, query, search-action, page-size, previous-action, page-status and next-action alongside its original grouped parts. Header, filters and pager omit controls placed separately. Query and Search retain one native form owner across containers. Paging and page-size changes use the last submitted search, not an unsubmitted draft. Lower-bound counts remain labeled at least.

Creation permission, immutable transition-history restrictions, pending writes and uncertain-save recovery remain native. A layout containing only individual navigation controls still exposes the original create form after New record. Refresh uses current reads and the existing recovery path.

Selected-record parts now include record-title, record-status, record-location, scope, relations-count, activity-count, secure-fields, related, transition-form, favorite-action, advance-action, edit-action, remove-action, actions and heading. The grouped detail and action areas omit separately placed controls. Scope uses the existing secured current-scope read; actions retain native permissions, record identity and recovery. The native edit form remains available. A list with children repeats its custom layout for each secured record. Row parts: row-open, row-title, row-status, row-created, row-updated, row-field, row-fields and row-favorite. Set fieldKey explicitly on row-field; missing, unknown or ambiguous keys show a useful unavailable state, never the first field. A list with no children retains the native rows. Nested workspaces clear outer row identities. Form controls are now independently placeable: form-heading, form-scope, form-title, form-status, form-fields, form-field, save-action and cancel-action. Give form-field an explicit fieldKey. A form with children renders a custom layout and retains unplaced controls; controls outside the form retain its native form association. The workspace owns visibility/location selection, exact field conversion, revision checks and uncertain-write recovery. Cancel stays locked during required review. The record-field part places one selected-record value using explicit fieldKey. Grouped detail/custom-fields omit values placed separately. A missing, unknown or ambiguous key produces a useful message; no selected record is inferred. A disclosure can contain the remaining detail/actions while keeping a key value prominent. Transition-form internals remain grouped. No new API routes, permissions or database contracts are introduced. Source examples and local browser tests are not routed-tenant or release acceptance.
