Fix render visit summary sections in configured order

[BlessedAmrita]

Summary

The visit summary PDF ignored each section's configured order. Section order is stored as report.visitSummary.section.<key>.order and the renderer already emits sections into the intermediate XML sorted by getOrder(), but visitSummaryFopStylesheet.xsl called each section's template from a hardcoded sequence, so the PDF always came out in that fixed order regardless of configuration. Enabling and disabling sections worked; reordering silently did nothing.

The root template now walks the XML in document order (<xsl:apply-templates select="*"/>), so the renderer's sort determines the PDF sequence. Each section's named template became a match template, which shortens its internal paths from document-root-relative to node-relative. Per-section output is unchanged. The footer is skipped in the body flow since it renders as fo:static-content on every page.

This surfaced now because the admin config page makes reordering possible for the first time.

Does this change existing PDFs?

No. With no order configured, each section's default order (facility header 100, patient info 200, vitals 300, diagnoses 400, conditions 450, lab results 475, allergies 500, medications 550, footer 900) produces the same sequence the hardcoded list did. Verified by transforming a default-ordered document through both the old and new stylesheet and diffing the FO output: byte identical, both for a fully populated document and one with empty sections plus section-notice / section-error siblings.

Related

Part of https://openmrs.atlassian.net/browse/O3-5667

Tests

130 passing, including 7 new: the pre-FOP XML sequence follows getOrder() including scrambled configurations, disabled sections are omitted, FO output follows document order, section errors stay beside their section, and the footer renders once.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[BlessedAmrita]

cc: @wikumChamith @dkayiwa