fix(render): surface an error for misconfigured/unhandled renderer tags instead of "[object Object]"

[mlennie]

Combines #2874 (Sagar) and #2875 (Monty) into one change, closing both.

A field whose renderer tag resolves to a renderer name that no plugin handles fell through apply-renderer's default branch to String(value). For a structured (record/array) value that produced the literal [object Object] filling the result panel. A common case: a child-only # big_value { sparkline=... } placed on a view with no activating # big_value (the plugin correctly declines to match since #2719). The Malloy lint already flags this, but render time showed garbage. Separately, once an error was thrown the ErrorBoundary rendered an empty red box rather than the message.

Changes

• When the validator has already flagged the field (e.g. the big_value case), surface its specific message ("Tag 'big_value' on field 'root' is only valid on basic fields inside big_value.") so the user sees exactly what is wrong. FieldBase records error-severity validateFieldTags findings; apply-renderer's default reads them.
• For any other structured value with no matching renderer, surface a generic "no renderer handled '' on field ''" message inline. Scalars and the none renderAs keep the existing string fallback, so a chart-child record is not mistaken for an error and one unhandled field does not blank the whole panel.
• render.tsx: the ErrorBoundary fallback now resolves the message from a thrown Error or a raw string, fixing a pre-existing bug where thrown render errors showed an empty red box (affects all render-time error display).
• docs/validation.md: documents the new inline render-time surfacing of producer-Drilling for Date and time fields #1 errors.

Before / after

Testing

• jest --selectProjects malloy-render passes; added a render-validator test for the exact view-level # big_value { sparkline=... } shape.
• Added a misconfigured_big_value Storybook story; verified via headless screenshots that the misconfig shows the specific error and that table / line / bar / dashboard / list / pivot / valid big_value stories are unaffected (the generic branch never false-fires on legit renderers or the none chart-child case).

Note for reviewers

This surfaces the error two ways depending on how the renderer fails: a plugin throw still routes to ErrorPlugin (unchanged); a plugin decline that leaves a field with no renderer but which the validator has flagged now shows that logged error inline rather than [object Object]. I considered rerouting the decline case through a plugin throw or a setup-time ErrorPlugin injection instead, but the throw path loses validateFieldTags coverage for "renders + one setting wrong" cases (e.g. # big_value { size=lg sparkline=x }, which should render and log, not red-box), and a setup-time injection would have to mirror the built-in renderer list to avoid replacing valid cell/dashboard renders. Flagging since it touches the validation contract; happy to take the decline case down a different route if you'd prefer.

A companion change in malloydata/publisher validates these tags at package-load time so a misconfigured tag also fails publish with a clear error rather than only surfacing at render time.