chore(ci): unblock master (docs drift, Scriban CVE, nav-title test)

[ottobolyos]

Summary

Unblock master's CI, red since 2026-06-26 on three independent failures in the Docs site + build-test-coverage DAG. All three fixes land in this PR so a single merge turns the whole DAG green.

• Regenerate docs/reference/http-api.md — every route handler's Source: line-number reference catches up with the current MTConnectHttpServer.cs line positions (shifted 4-22 lines by the 2026-06-26 v7.0-prerelease HTTP Server edits). Line-number metadata only; page content unchanged.
• Bump Scriban from 7.2.0 to 7.2.2 in build/MTConnect.NET-SysML-Import to clear NU1902/NU1903 CVE errors (GHSA-6q7j-xr26-3h2c, GHSA-7jvp-hj45-2f2m, GHSA-q6rr-fm2g-g5x8) that fail the API-ref build under <TreatWarningsAsErrors>. Matches dependabot PR Bump Scriban from 7.2.0 to 7.2.2 #204; supersedes it.
• Update RouteCheckTests.Landing_Page_Carries_The_House_Style_Surfaces to assert the nav-bar renders the plain-text title MTConnect.NET (per maintainer commit c2041ce "Updated Docs Site", 2026-06-26: themeConfig.logo was removed on the grounds that "logo might be too small to read"). The prior assertion checked for an <img> inside .VPNavBarTitle that no longer exists. The hero-image assertion, favicon assertion, and social-card assertions remain in force.

[ottobolyos]

Some context on how this drift landed and how it could keep landing.

What broke

docs.yml has a Prepare generated docs job whose first step runs docs/scripts/generate-reference.sh --check. It compares the committed docs/reference/*.md pages against what the Roslyn generator would emit from the current source, and exits non-zero on drift. Working as designed.

When the v7.0-prerelease landings on 2026-06-26 edited MTConnectHttpServer.cs (PR #201 + several direct pushes), every route handler's line-number reference in docs/reference/http-api.md went stale by 4-22 lines. The drift gate has been red on master since — visible in Actions, blocking no merges.

Why it kept blocking every PR

master currently has no branch protection (gh api repos/TrakHound/MTConnect.NET/branches/master/protection returns nulls across the board). So:

• Direct pushes to master land whether or not Docs site is green.
• PR merges don't wait for Docs site either.
• Rebased PR branches inherit master's stale committed docs and thus inherit the drift — every open PR gets the same red gate on every CI run, blocking the entire downstream DAG (build-and-test, route-check-e2e, Build VitePress site, Check internal links, Deploy to GitHub Pages).

What would prevent recurrence

Two levers, in decreasing order of impact:

1. Enable branch protection on master with Prepare generated docs (and ideally build-and-test, route-check-e2e) as required status checks — Settings > Branches > Add rule for master. Blocks direct-push and PR-merge alike when the DAG is red.

2. Optional in-repo backup: a small .github/workflows/master-drift-alert.yml that runs the drift gate on schedule (every ~6 h) against master's tip and opens or updates a tracking issue on failure. Non-blocking, but makes the failure visible even without watching Actions. Happy to open a follow-up PR if this is useful.

[ottobolyos]

Merge train (§1.5b + §1.5d)

This PR joins the current train as the new queue head. Order:

• chore(ci): unblock master (docs drift, Scriban CVE, nav-title test) #205 — chore(docs): regenerate http-api reference to clear drift gate (this PR, queue head)
• fix(common): coerce null/empty/whitespace observation Result to UNAVAILABLE #193 — fix(common): coerce null/empty/whitespace observation Result to UNAVAILABLE
• fix(build): restore multi-TFM compatibility for Release pack #194 — fix(build): restore multi-TFM compatibility for Release pack
• fix(build): clean every Release-pack warning + add multi-TFM CI gate #195 — fix(build): clean every Release-pack warning + add multi-TFM CI gate

Rationale: #205 is a docs-only chore, unblocks the entire Docs site + build-and-test + route-check-e2e job DAG that is currently red on every push and every PR against master, so it merges first. #193/#194/#195 are all base=master (independent, not stacked); their merge order follows PR number ascending per §1.5b.

Integration branches (§1.5d):

• No integration branch for chore(ci): unblock master (docs drift, Scriban CVE, nav-title test) #205 (queue head; its own tip IS the integration point per §1.5d).
• integration/up-to-pr-193 = upstream/master + #205 + #193.
• integration/up-to-pr-194 = upstream/master + #205 + #193 + #194.
• integration/up-to-pr-195 = upstream/master + #205 + #193 + #194 + #195.

Stale integration branches from the prior (empty since 2026-06-06) train — integration/up-to-pr-182, -186, -187, -188 — are due to be cleaned up per §1.5d L1598.