[BUG]: `ModeBar` generated type should be more specific

Description

The generated ModeBar type in src/types/generated/components/modebar.d.ts is less specific than the hand-written ModeBar in @types/plotly.js. The type generator faithfully maps valType: 'string' to string and valType: 'any' to any, but this loses semantic type information for the add, remove, and uirevision properties.

Consumers lose autocomplete for valid modebar button names when using layout.modebar.add or layout.modebar.remove.

Steps to reproduce

1. Use layout.modebar.add in a TypeScript project importing from plotly.js
2. Observe that the type accepts any string instead of suggesting valid button names like 'lasso2d', 'select2d', 'zoom2d', etc.

Notes

Root cause: The add and remove attributes in src/components/modebar/attributes.ts use valType: 'string' with arrayOk: true. The type generation pipeline (ValTypeToTS in src/types/lib/attributes.d.ts) already supports narrowing StringAttr to a literal union when a values array is provided — but the modebar attributes don't provide one. The button names are dynamically computed at runtime in src/components/modebar/constants.js (foreButtons is built by iterating over the button registry), so they can't be passed as a static as const array.

Possible solutions:

1. Override the generated type in layout.d.ts — Import the generated ModeBar and re-export a refined version using Omit + tighter property types. Keeps the generated base while tightening the public API. Low effort, no changes to the generator or attribute system.

2. Inline static values in the attribute definition — Add values: ['lasso2d', 'select2d', ...] as const directly to the add and remove attributes in src/components/modebar/attributes.ts. The existing ValTypeToTS conditional would then produce the union automatically. Downside: duplicates the button list (source of truth is the button registry, not this array).

3. Make foreButtons statically typed — Convert src/components/modebar/constants.js to TypeScript with static as const arrays instead of dynamically computing the list from the button registry. The attributes could then reference the const array as values. Downside: requires restructuring how buttons are registered and breaks the dynamic discovery pattern.

Start with src/types/generated/components/modebar.d.ts, src/components/modebar/attributes.ts, and src/types/lib/attributes.d.ts to trace how ModeBar properties become TypeScript types. Read src/components/modebar/constants.js to understand the runtime button registry before evaluating the possible approaches. Done means add and remove expose the intended button-name type, uirevision is number | string, and uid is present without losing the generated type structure.