[sergioperezcheco]

Restore function-name handlers in HTML output

FunctionNode.toHTML silently ignores the documented object form of options.handler. For example:

math.parse('f(2)').toHTML({ handler: { f: () => '<em>custom</em>' } })

This currently produces the default function markup instead of <em>custom</em>. The generic callback form was fixed previously, but named-function dispatch is still missing. This addresses the remaining handler-map case discussed in #2425; it does not change the generic callback implementation.

Dispatch own function-name handlers before the default renderer, preserving the original options object for recursive rendering. An undefined result falls back to the existing renderer; an empty string remains a valid result. Inherited properties are not treated as handlers. The default markup and callback form remain unchanged.

Verification

Five regression tests cover nested rendering, fallback, empty results, null-prototype and inherited maps, and the callback form. The unchanged production code fails four new cases; the patch passes all 49 FunctionNode tests. Independently checked parsed root, nested and sibling calls through the public API against the baseline and fixed code.

Locally ran the full source suite, uncached lint, TypeScript checks, coverage, Firefox headless browser tests, and rebuilt ESM/CJS/UMD public-entry checks. npm run build-and-test passed in validation, but also intermittently fails the existing CLI should interpret scripts output-order assertion. The pristine baseline fails the same assertion; a separate final rerun encountered it again. No CLI tests or production code were changed to mask this. The Node/OS and remote browser CI matrices have not been run locally.

This contribution was implemented and reviewed by autonomous AI agents; it has not received human review.