Restore sparse per-component module loading

[malberts]

Closes #68.

Restores BC's intended sparse-loading scheme by closing the two gaps that broke it. +5 lines across 2 source files.

Root cause

BC was designed to load each component's .fix ResourceLoader module only on pages that actually use that component — sparse, on-demand loading. The mechanism: each component calls BootstrapComponentsService::registerComponentAsActive($name) when used, and HooksHandler::onParserAfterParse iterates the registered set to queue the per-component modules. Two gaps broke that scheme:

1. Only ImageModal::177 called registerComponentAsActive(). The 11 explicit-syntax components (Accordion, Alert, Badge, Button, Card, Carousel, Collapse, Jumbotron, Modal, Popover, Tooltip) never registered themselves, so the foreach never iterated over them — their .fix modules were never queued, CSS or JS. ImageModal was the only one that worked.
2. The foreach only called $parserOutput->addModuleStyles() (CSS only). Modules with a scripts: entry (tooltip.fix, popover.fix, carousel.fix) never had their JS half loaded — addModuleStyles doesn't cover that.

Fix

Two one-line additions, at the right architectural layer in each case:

• AbstractComponent::parseComponent() now calls registerComponentAsActive($this->getComponentName()) right after $nestingController->open($this). All 11 explicit-syntax components inherit this via the single chokepoint. The service is fetched via MediaWikiServices::getInstance()->getService(...), matching the service-locator pattern already used by LuaLibrary, CarouselGallery, and ImageModal in the codebase.
• HooksHandler::onParserAfterParse foreach now calls both addModuleStyles([$module]) and addModules([$module]). Style-only modules treat the latter as a no-op; modules with a scripts: entry get their JS init loaded.

Scope

• 2 source files (AbstractComponent.php, HooksHandler.php), +5 lines / -0
• 1 test file (HooksHandlerTest.php), +59 lines / -0 — new unit test pinning the foreach addModules contract
• No constructor changes — uses the existing service-locator pattern

Verification

Tested on MW 1.43.8 + Chameleon BS4 (where the bug manifests) and on the oldest supported floor MW 1.39.17 + Vector:

	Sparse loading working?	Interactions firing?
MW 1.43.8 + Chameleon BS4 — TooltipPopoverTest page	tooltip.fix + popover.fix = ready ✓; carousel.fix = registered (not loaded — sparse!) ✓	tooltip popup ✓; popover popup ✓
MW 1.43.8 + Chameleon BS4 — ModalTest page	modal.fix = ready ✓; tooltip / popover / carousel .fix all stay registered (no triggers on this page) ✓	modal opens (.show, backdrop, body.modal-open) ✓
MW 1.39.17 + Vector — TooltipPopoverTest page	same shape as 1.43.8 row 1 ✓	same ✓
MW 1.39.17 + Chameleon BS4 — TooltipPopoverTest page	same shape ✓	same ✓
MW 1.39.17 + Medik — TooltipPopoverTest page	same shape ✓	same ✓

Visual confirmation of the interactions:

	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

The sparse-load assertion is the key new evidence: on a tooltip-only page, only tooltip.fix + popover.fix load. On a modal-only page, only modal.fix loads. On a page with nothing, no BC init modules load. Original design intent restored.

Tests

New: HooksHandlerTest::testOnParserAfterParseLoadsActiveComponentScriptsAndStyles asserts that the foreach calls both addModuleStyles AND addModules per active component'"'"'s module — pins the contract this PR restores against future regressions.

PHPUnit (--group mediawiki-databaseless) on MW 1.39: 339 tests, 537 assertions, 6 failures — baseline plus one new test, no new failures (same 6 pre-existing BootstrapComponentsServiceTest / ImageModalTriggerTest / ImageModalTest failures, all unrelated to the module-loading path).

[JeroenDeDauw]

I see lots of LOC, mocks, and binding to details for testing one line of production code. Highly sus and likely notably net-negative