EXPRESS production tests

These pages are a rendered, exhaustive corpus for the ExpressLexer (pygments_step.express). Every page is a production test: the snippets below are highlighted and must lex cleanly. Two layers of automation hold them to that promise:

1. The docs build. The site is built with mkdocs build --strict in the docs GitHub Actions workflow. A lexing or linking error turns the build red, so a broken snippet blocks the deploy.
2. The pytest suite. tests/test_docs_pages.py parses every express fence on every page under docs, the demo page included, and asserts that the lexer produces zero Error tokens, and that each page really contains the whole family of tokens it claims to cover.

Use these pages the way you would use a checklist: pick an EXPRESS construct you are changing, find its page, and confirm the highlighting matches what you expect. If the lexer ever stops recognising something, the relevant page stops being green.

Pages

Page	What it exercises
Keywords	Every reserved word (ISO 10303-11, clause 7.2, table 1)
Operators	Word operators (table 2) and every symbolic operator
Declarations	Declaration heads and the declared name token
Types	Aggregation types and built-in types
Constants	Built-in constants (table 3), incl. ? and SELF
Built-ins	Built-in functions (table 4) and procedures (table 5)
Literals	Strings, encoded and binary literals, reals and integers
Remarks	Nested (* ... *) and -- tail remarks

The EXPRESS lexer is case-insensitive: a literal inside the syntax rules is case independent (ISO 10303-11:2004, clause 6.1) and annex A.1.1 states that a keyword may be given in upper, lower or mixed case, so each page shows the canonical upper-case form and every snippet is valid lower-case too.

Clause and table numbers on these pages follow ISO 10303-11:2004. The rules inside its syntax boxes carry their own numbers (annex A), which the lexer comments cite as syntax rule N.