Refresh the reserved-HTML-id check in identifier-warning

[rbeezer]

The identifier-warning template fatally rejects an identifier that equals a fixed HTML @id the CSS/JS depend on. That list had gone stale (it still named the pre-modern-theme masthead/content/primary-navbar/sidebar-left/sidebar-right/toc), so it guarded ids that no longer exist and missed the current ones. This audits the list against today's HTML output and folds the whole template into one loop over .//@xml:id | .//@label, since either attribute can become an element's HTML @id.

Reserved ids (always):
ptx-masthead, ptx-content, ptx-content-footer, ptx-page-footer, ptx-navbar, ptx-sidebar, ptx-toc, mainmatter, logo-link, latex-macros, ptxsearch, searchbutton, searchresults, searchresultsplaceholder, searchempty, closesearchresults, light-dark-button, papersize-select, highlight-workspace-checkbox, hide-hint-checkbox, hide-answer-checkbox, hide-solution-checkbox, print-first-page-header-checkbox, print-running-header-checkbox, print-first-page-footer-checkbox, print-running-footer-checkbox, calculator-toggle, calculator-container, geogebra-calculator, embed-button, embed-popup, embed-code-textbox, copy-embed-button

Reserved ids (only when $b-host-runestone):
inst_peer_link, ip_dropdown_link, subchapterprogress, scprogresscontainer, scprogressposs, scprogresstotal

Other notes:

• The list is a tokenized variable; the test is the existential . = $reserved-html-id-tokens.
• Both @xml:id and @label are checked against it. Mildly over-aggressive (a reserved @xml:id shadowed by a good @label is internal-only and couldn't really collide), commented as such and tied to the assembly @label-precedence.
• Behavior unchanged otherwise: character-set and reserved-id checks now name the offending attribute (@xml:id/@label); reserved-id is PTX:FATAL, bad characters and an index clash stay non-fatal.

Tested by temporarily corrupting sample-article / sample-book identifiers and building -vv … -f latex (and an HTML Runestone build for the conditional ids), confirming each case fires and valid identifiers do not.

Claude Opus 4.8, acting as a coding assistant for Rob Beezer

[rbeezer]

Updated (force-push): the six Runestone Services ids are now banned unconditionally, rather than only under $b-host-runestone.

Reasoning: those components (inst_peer_link, ip_dropdown_link, subchapterprogress, scprogresscontainer, scprogressposs, scprogresstotal) can appear via Runestone Services even on a build that is not hosted on Runestone, so the collision risk exists there. Conversely, on a genuinely hosted Runestone build the HTML ids get mangled, so the risk there is actually small. Banning them always covers the case that matters.

They remain a separate, commented group in $reserved-html-ids, distinct from the core PreTeXt UI ids. $b-host-runestone is no longer referenced by the template.

So the description's "only when $b-host-runestone" note no longer applies — those ids belong with the always-reserved set.

Claude Opus 4.8, acting as a coding assistant for Rob Beezer