fix(spec): the bulk-param migration entry names the promoted field-backed route

The major-18 semantic entry ui-bulk-action-param-unknown-keys-refused said
the bulk surface has no field-backed param route. Since objectui 29b99490
(carried by the console pin) a promoted bulk action resolves its field-backed
params through the single-record dialog's resolver, and accept / maxSize
arrive from the field. The replacement and reason clauses now say the
AUTHORED bulkActionDefs[].params surface has no such route and name the
promoted one, in the wording BulkActionParamSchema's rejection text uses.

Claude-Session: https://claude.ai/code/session_01KNKBCRDJCu5tGy3TEbvtrF
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/22858-bulk-param-promoted-route-migration-text.md

@@ -0,0 +1,14 @@
+---
+'@objectstack/spec': patch
+---
+
+fix(spec): the `ui-bulk-action-param-unknown-keys-refused` upgrade guidance names the promoted field-backed bulk route instead of saying the bulk surface has none (#22858)
+
+Clause-②: no
+
+The major-18 semantic entry `ui-bulk-action-param-unknown-keys-refused`, which `objectstack migrate meta` prints, said two things that stopped being true once the console resolved a promoted bulk action's params through the single-record dialog's resolver. It called `field` / `objectOverride` contracts "the bulk surface does not implement", and it told the reader that declaring a widget-config key on the object's field cannot help because "the bulk surface has no field-backed param route". The entry now uses the wording the `BulkActionParamSchema` rejection messages already use.
+
+- **`replacement`.** An authored `bulkActionDefs[].params` entry has no field-backed route: it reaches the dialog as written. The `field` rejection offers two fixes: declare the param inline, or declare the action on the object with the field-backed param and name it in the view's `bulkActions`. That second form is the promoted route, whose params are resolved when the bulk dialog opens. Of the widget-config keys, only `accept` / `maxSize` declared on the field reach the dialog, through a promoted action. `carryOver` / `defaultFromRow` / `requiresFeature` are still ACTION-param contracts the bulk surface does not implement.
+- **`reason`.** Declaring the key on the field and keeping the authored def still does not reach the dialog. A promoted action is the one route that consults the field. Of the refused keys, only `accept` / `maxSize` arrive that way. `lookupFilters` / `lookupColumns` / `lookupPageSize` / `descriptionField` are resolved and then dropped on the bulk path, and the rest are never read off the field.
+
+Nothing to migrate: the accepted and refused keys are unchanged. Only the guidance text of one migration entry moved.

packages/spec/src/migrations/entries/semantic/18.ui-bulk-action-param-unknown-keys-refused.ts

@@ -22,14 +22,22 @@ export const entry: SemanticMigration = {
     + '`help`, `defaultValue` → `default`, `reference` → `object`, `displayField` → '
     + '`labelField`); the keys that belong one layer out are pointed there (`visible` and a '
     + 'capability gate belong on the DEF, `visibleWhen` belongs on an `options[]` entry, '
-    + '`field` / `objectOverride` / `carryOver` / `defaultFromRow` / `requiresFeature` are '
-    + 'field-backed ACTION-param contracts the bulk surface does not implement); and the '
-    + 'widget-config family (`min`, `max`, `step`, `precision`, `scale`, `rows`, `accept`, '
-    + '`maxSize`, and the picker knobs `lookupFilters` / `lookupColumns` / `lookupPageSize` / '
+    + '`carryOver` / `defaultFromRow` / `requiresFeature` are ACTION-param contracts the bulk '
+    + 'surface does not implement); `field` / `objectOverride` declare a FIELD-BACKED param, '
+    + 'and an authored `bulkActionDefs[].params` entry has no such route — it reaches the '
+    + 'dialog as written, and nothing on that path resolves it against the object\'s field '
+    + 'definitions — so the `field` rejection offers two fixes: declare the param inline, or '
+    + 'declare the action on the object with that field-backed param and name it in the '
+    + 'view\'s `bulkActions`, the PROMOTED route, whose params are resolved through the '
+    + 'single-record dialog\'s resolver when the bulk dialog opens; and the widget-config '
+    + 'family (`min`, `max`, `step`, `precision`, `scale`, `rows`, `accept`, `maxSize`, and '
+    + 'the picker knobs `lookupFilters` / `lookupColumns` / `lookupPageSize` / '
     + '`descriptionField` / `picker` / `subtitle` / `avatarField` / `idField` / `allowCreate`) '
     + 'is answered with one prescription naming `FieldSchema` as the shape those keys are real '
-    + 'on. `dependsOn` needs NO edit — it is declared, in the same shape the field-level key '
-    + 'takes (`[\'parent\']`, or `[{ field, param }]` when the remote filter key differs).',
+    + 'on, and saying that of them only `accept` / `maxSize` declared there reach this dialog, '
+    + 'through a promoted action. `dependsOn` needs NO edit — it is declared, in the same '
+    + 'shape the field-level key takes (`[\'parent\']`, or `[{ field, param }]` when the remote '
+    + 'filter key differs).',
   reason:
     'The accept was a NULL READING, and that is what makes this a contract fix rather than a '
     + 'preference. Measured against installed spec 17.4.0, three parses per schema in one '
@@ -51,11 +59,18 @@ export const entry: SemanticMigration = {
     + 'accepted cost of closing the shape (maintainer ruling, letter '
     + 'A, 2026-09-17: 「Breaking for authored metadata」, one-shot, no grace window and no dual '
     + 'spelling). ⛔ Do not read their rejection as "the renderer ignores them", and ⛔ do not '
-    + 'answer it by declaring the key on the object\'s FIELD: the bulk surface has no '
-    + 'field-backed param route, so that value does not reach this dialog either. A census of '
-    + 'authored bulk params taken at registration time over the two repositories reachable from '
-    + 'that session found ZERO carrying an undeclared key (objectstack@176b03582e: 7 param '
-    + 'literals; objectui@3e4f6324f7: 3), so no in-corpus configuration is known to break. '
+    + 'answer it by declaring the key on the object\'s FIELD and keeping the authored def: an '
+    + 'authored `bulkActionDefs[].params` entry has no field-backed param route, so that value '
+    + 'does not reach this dialog either. The one route that consults the field is a PROMOTED '
+    + 'action — an action the object declares, named in the view\'s `bulkActions`, whose '
+    + 'field-backed params (`{ field }`) are resolved through the single-record dialog\'s '
+    + 'resolver when the bulk dialog opens — and of these keys only `accept` / `maxSize` arrive '
+    + 'that way: `lookupFilters` / `lookupColumns` / `lookupPageSize` / `descriptionField` are '
+    + 'resolved and then dropped on the bulk path, and the rest are never read off the field. '
+    + 'A census of authored bulk params taken at registration time over the two repositories '
+    + 'reachable from that session found ZERO carrying an undeclared key '
+    + '(objectstack@176b03582e: 7 param literals; objectui@3e4f6324f7: 3), so no in-corpus '
+    + 'configuration is known to break. '
     + '⚠️ That census did NOT cover hotcrm, which was unreachable from the session that took it '
     + '— that leg is UNMEASURED, not clean, and an upgrader with their own metadata corpus '
     + 'should run the check below rather than inherit this result.',