docs(plugin-dashboard): cite the spec format description by the change that wrote it

The FieldSchema.format wording the comments lean on landed in
objectstack#19763; the spec version this repo builds against still carries
the older one-line description, so the comments now name the change rather
than claim the installed package says it. Also give the inline comment's
"those letters" its antecedent.

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

Author: claude

packages/plugin-dashboard/src/__tests__/recordFields.formatHintNotDatePattern-10220.test.tsx

@@ -35,11 +35,12 @@
  *
  * A hint-word exclusion list would be a second copy of the resolver's
  * vocabulary, kept in step by hand — and the autonumber case above shows it
- * would still be incomplete. `@objectstack/spec` already describes `format` as
- * type-dependent (`FieldSchema.format`: the `date` and `datetime` cells read it
- * as a display style; plain-text fields read a small set of renderer-hint
- * words). So the branch now asks the question that description asks: is this
- * a `date` / `datetime` field? A field whose type is unknown is not a date
+ * would still be incomplete. The `FieldSchema.format` description
+ * objectstack#19763 wrote for `@objectstack/spec` already treats `format` as
+ * type-dependent: the `date` and `datetime` cells read it as a display style,
+ * and plain-text fields read a small set of renderer-hint words. So the branch
+ * now asks the question that description asks: is this a `date` / `datetime`
+ * field? A field whose type is unknown is not a date
  * cell either — a column with no schema type declares one (`type: 'date'`) to
  * get the date face, which the last case below pins.
  *

packages/plugin-dashboard/src/recordFields.tsx

@@ -69,11 +69,12 @@ export const NUMERIC_FIELD_TYPES = new Set([
  * Field types whose `format` {@link renderFieldValue} reads as a date display
  * pattern (objectui#10220).
  *
- * `format` has one key and several readers, each with its own vocabulary —
- * `@objectstack/spec` says so in `FieldSchema.format`'s own description: the
- * `date` / `datetime` cells read it as a display style, while on a plain-text
- * field the shared resolver (`resolveCellRendererType`, `@object-ui/fields`)
- * reads a small set of renderer-hint words. The date branch used to fire on any
+ * `format` has one key and several readers, each with its own vocabulary. The
+ * `FieldSchema.format` description objectstack#19763 wrote for
+ * `@objectstack/spec` says so: the `date` / `datetime` cells read it as a
+ * display style, while on a plain-text field the shared resolver
+ * (`resolveCellRendererType`, `@object-ui/fields`) reads a small set of
+ * renderer-hint words. The date branch used to fire on any
  * `format` containing a Y / M / D / H / m / s letter, whatever the field's type,
  * so `format: 'email'` (it has an `m`) sent an address to `formatDate` and
  * painted an em dash. So did an `autonumber` record-number pattern carrying
@@ -451,8 +452,8 @@ export function renderFieldValue(
   }
   // A date pattern only on a date field (objectui#10220) — see
   // `DATE_PATTERN_FIELD_TYPES` for why the gate is the type. A date field's
-  // style word with none of those letters (`relative`) still falls through to
-  // its cell renderer below, as before.
+  // style word that carries none of the Y / M / D / H / m / s letters
+  // (`relative`) still falls through to its cell renderer below, as before.
   if (
     typeof fmt === 'string'
     && DATE_PATTERN_FIELD_TYPES.has(fieldMeta.type as string)