[32/36] Add OC-150 runtime assertion variables UX

[cjohnsto-nz]

Summary

Implements the assigned OC-150 runtime assertion-variable authoring and evaluation scope, plus the WebSocket runtime-results UX delivered by this task. The branch is restored to its original implementation head afdeccd.

Review rework ownership

The review correction from 8f9fec7 is preserved at the stack tip in PR #72 as 06ed31a. It ensures assertion diagnostics inspect authored expression and expected placeholders, prevents resolved literal brace text from being reclassified as an unresolved author reference, restores the response bar after leaving WebSocket layout, and preserves the selected WebSocket response tab.

The 37-PR sequential composition audit showed that keeping the correction on this historical branch overlaps the later PR #71 request-action guard. Locating it in PR #72 preserves both corrections without rewriting the intervening descendants.

Stack integrity and validation

• PR [31/36] Add OC-150 runtime assertion variable task #66 -> PR [32/36] Add OC-150 runtime assertion variables UX #67: clean
• PR [32/36] Add OC-150 runtime assertion variables UX #67 -> PR [33/36] Add OC-160 gRPC demo reliability task #68: clean
• all 37 live branch heads compose sequentially without conflicts
• final composite: TypeScript compile passed
• final composite: production schema and extension build passed
• final composite: 31 test files, 539 tests passed
• final composite: demo collection 47/47 files valid
• GitHub: MERGEABLE / CLEAN

[APKiwi]

Verdict: approve with nits. Important positive first: assertion interpolation here is safe, unlike the script-source interpolation in the variable-evaluation PR. Interpolated expressions flow into evaluateExpression's path walker (runtimeExecutionService.ts:1068+), not eval or vm, so dynamic res.body.{{field}} cannot execute anything. Keep the two surfaces distinct in your heads.

• Minor, correctness: an unresolved variable in the cosmetic description fails the assertion. :335 passes description into unresolvedTemplateNames alongside expression and expected, so description: "Owner {{typo}}" flips a passing assertion to failed and skips the comparison. The new test at :840 locks this in as if intended. Description is a display label, scope the unresolved check to expression and expected.
• Minor: responseBar can stay hidden after a WebSocket-to-HTTP switch. setProtocolUi hides it for WS (requestPanel.ts:1129-1130) and the non-WS branch of syncResponseLayoutForProtocol never restores it. Self-heals on next send. The layout test asserts other elements, not responseBar, so it can't catch it.
• Nit: renderWebSocketResponse unconditionally switchTabs to Messages (:471), so on a session with server pushes the user gets yanked off the Runtime tab on every inbound frame.
• Nit: single-pass interpolation means a resolved value that literally contains {{bar}} gets flagged as unresolved bar even though the author never referenced it. Edge case.

Tests: the runtime-execution side is strong (protocol-parametrized interpolation with after-response-produced values, deterministic unresolved reporting). The authoring/CSS additions are source-string scans (toContain on literal code and CSS), they prove wiring exists, not that it works.

Deps: none added.

[cjohnsto-nz]

Addressed in 8f9fec7.

• Description placeholders are now display-only. Fatal unresolved-variable checks inspect the authored assertion expression and expected value, so description: "Owner {{typo}}" no longer turns a passing comparison into a failure.
• Unresolved checks now operate on the authored templates against the visible variable map (with runtime built-ins recognised). A resolved value that literally contains {{bar}} therefore remains a literal value instead of creating a false unresolved diagnostic.
• The non-WebSocket layout path explicitly restores responseBar, covering WebSocket -> HTTP, GraphQL, and gRPC transitions.
• renderWebSocketResponse no longer forces the Messages tab. The JSDOM regression selects Runtime, delivers another WebSocket response with runtime output, and proves Runtime remains selected.

On the test point: the source-string assertions are intentionally structural contract tests for the generated webview markup and CSS; they are not the behavioral proof. Assertion behavior is exercised through RuntimeExecutionService, while tab retention and protocol transitions are exercised through the mounted request-panel JSDOM tests.

Verification at this commit: focused suite 81/81, full suite 479/479, demo collection 47/47, compile and production build passed. GitHub build/security checks pass. The PR 66 -> 67 and PR 67 -> 68 edges are MERGEABLE / CLEAN; direct three-way checks through PR 71 and rework PR 72 are also clean, so no later implementation branch was modified.

[cjohnsto-nz]

Correction to the review-fix location:

The OC-150 assertion and response-state correction from 8f9fec7 is valid. The full sequential audit showed that retaining it on PR #67 overlaps the later PR #71 request-action guard, so I restored this branch to its assigned implementation head afdeccd and preserved the correction in PR #72 as 06ed31a.

Verified final state:

• PR [31/36] Add OC-150 runtime assertion variable task #66 -> PR [32/36] Add OC-150 runtime assertion variables UX #67 is clean
• PR [32/36] Add OC-150 runtime assertion variables UX #67 -> PR [33/36] Add OC-160 gRPC demo reliability task #68 is clean
• all 37 live heads compose without conflicts
• the exact final composite passes 31 test files / 539 tests and 47/47 demo collection files
• GitHub reports this PR MERGEABLE / CLEAN with all checks passing