Load per-component JS init modules so tooltip/popover open on MediaWiki 1.43+

[malberts]

Closes #68.

Completes the fix for #68 by resolving the tooltip, popover and carousel sub-bugs left out of #75 (which addressed only the modal symptom).

Root cause

The per-component JS init modules ext.bootstrapComponents.{tooltip,popover,carousel}.fix each declare a scripts: entry in extension.json that initialises the Bootstrap library on the trigger elements (.tooltip(), .popover(), .carousel()). Without these modules reaching the page, hover on a .bootstrap-tooltip and click on a [data-toggle="popover"] do nothing.

HooksHandler::onParserAfterParse is supposed to load them via the getActiveComponents() foreach, but two issues break that path:

1. Only ImageModal registers itself as active. Tooltip, popover, and carousel parser hooks never call registerComponentAsActive(), so getActiveComponents() never contains them and the foreach never iterates over their modules.
2. Even when the foreach does run (for ImageModal), it calls addModuleStyles() — which loads only the CSS half. The scripts: half of a module never reaches the page through that call.

Fix

Move per-component init module loading to OutputPageParserOutput::process(), where the three init modules are added unconditionally to the persistent OutputPage via addModules(). Each init script is a single jQuery selector + initializer call ($('[data-toggle="tooltip"]').tooltip() etc.); on a page without the matching trigger markup the selector returns an empty collection and the initializer no-ops. Per-request cost on tooltip/popover/carousel-free pages: three small DOM queries served from a cached ResourceLoader bundle — negligible.

Scope

• 1 source file: src/Hooks/OutputPageParserOutput.php — adds one addModules call in process() listing the three per-component init modules
• 1 test file: tests/phpunit/Unit/Hooks/OutputPageParserOutputTest.php (rewritten the two process() cases to assert the union of addModules calls — same mocking pattern PR Fix modal trigger not opening modals on MediaWiki 1.43+ #75 used in testHookOutputPageParserOutputLoadsModules)

Net: +37 / −7 lines.

Verification

Tested on MW 1.43.8 + Chameleon BS4 (where the bug manifests) and on the oldest supported floor MW 1.39.17 across three BS4 skins — Vector, Chameleon BS4, and Medik:

	Tooltip hover	Popover click
MW 1.43.8 + Chameleon BS4
MW 1.39.17 + Vector
MW 1.39.17 + Chameleon BS4
MW 1.39.17 + Medik

Module + instance state on both stacks after page load:

ext.bootstrap.scripts:                ready
ext.bootstrapComponents.tooltip.fix:  ready
ext.bootstrapComponents.popover.fix:  ready
ext.bootstrapComponents.carousel.fix: ready
jQuery(.bootstrap-tooltip).data("bs.tooltip"):   <object>
jQuery([data-toggle=popover]).data("bs.popover"): <object>

Tests

PHPUnit (--group mediawiki-databaseless) on MW 1.39:

	Tests	Failures
Master (post-#75)	338	6
Patched (this PR)	338	6

Same 6 pre-existing failures in BootstrapComponentsServiceTest / ImageModalTriggerTest / ImageModalTest (manual-thumbnail variants). All unrelated to the JS-init module path.

🤖 Generated with Claude Code

[malberts]

Superseded by #80 — that PR closes the same #68 sub-bugs but takes the architecturally-correct path: restores BC's intended sparse-loading scheme via the AbstractComponent chokepoint, rather than this PR's unconditional-load workaround in OutputPageParserOutput::process().

Net: #80 is +5 lines / -0 (vs #79's +37 / -7), with no workaround-flavour code, and on a tooltip-only page only tooltip.fix loads (#79 would have unconditionally loaded all three).