[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.

Comienza con src/types/generated/components/modebar.d.ts, src/components/modebar/attributes.ts y src/types/lib/attributes.d.ts para rastrear cómo las propiedades de ModeBar se convierten en tipos de TypeScript. Lee src/components/modebar/constants.js para entender el registro de botones en tiempo de ejecución antes de evaluar los posibles enfoques. Se considera completado cuando add y remove exponen el tipo de nombre de botón previsto, uirevision es number | string y uid está presente sin perder la estructura de tipos generada.