test(md_help): expect the guttered console block per syntax-highlighting

[worktrunk-bot]

cargo hack test --feature-powerset fails on the --no-default-features --features cli combination: test_html_comment_inside_a_code_block_is_content baked the highlighted rendering of its trailing ```console block into one inline snapshot, and with syntax-highlighting off that block renders plain. Split the expectation into a #[cfg(feature = "syntax-highlighting")] / #[cfg(not(...))] pair — the shape src/styling/format.rs already uses — so both configurations keep the assertion rather than one of them losing it. Verified by running the test under both feature sets locally.

Detail

The failing diff:

    1     1 │ [107m [0m [2m<!-- wt list -->[0m
    2     2 │
    3       │-[107m [0m [2m[0m[2m[34mwt[0m
          3 │+[107m [0m wt

syntax-highlighting is a default feature, so the required checks (test (linux|macos|windows), fast-checks) build with it on and never see this; only feature-powerset exercises cli without it. That job's own comment in nightly.yaml names this exact case — "a snapshot baking feature-dependent output, only surfaces when tests are built and run per combo".

Introduced by #3908, which landed after main's last nightly run, so no run on main had caught it yet. It surfaced on #3915 (an unrelated Dependabot bump), where the red check was confusing enough to be worth clearing.

The test's subject is that a fenced <!-- wt list --> is content and its marker does not leak into the following block. Both cfg variants assert that; only the trailing block's colouring differs, which is why gating the whole assertion on the feature would have been the wrong trade.

Test plan

cargo test --bin wt md_help                                        # 27 passed
cargo test --no-default-features --features cli --bin wt md_help   # 27 passed

The second command reproduces the failure at 8e40a2b7 and passes here. cargo fmt --check and cargo clippy --no-default-features --features cli are clean.

[worktrunk-bot]

One thing worth flagging: feature-powerset — the job this fixes — is skipped on this PR. The nightly gate ran it on #3915 (which touches .github/workflows/nightly.yaml) but resolved to skip on a src/-only change, so CI here never exercises the combination the fix is for.

So the verification is the local run in the PR body, not a check on this head: cargo test --no-default-features --features cli --bin wt md_help reproduces the failure at 8e40a2b7 and passes with this commit. Worth a manual nightly dispatch before merging if you want the powerset job's word on it.

[worktrunk-bot]

The nightly cron on main has now hit this, which is the confirmation my earlier comment said was missing from this PR's own checks: run 32935569443 on e4238e8, feature-powerset red on cargo test --no-default-features --features cli:

test md_help::tests::test_html_comment_inside_a_code_block_is_content ... FAILED
test result: FAILED. 980 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
error: process didn't exit successfully: `cargo test --manifest-path Cargo.toml --no-default-features --features cli` (exit status: 101)

Same test, same feature combination as this PR fixes, so no separate fix PR — this one covers it. Adding the nightly label here would get the powerset job to run on this head rather than relying on the local reproduction.

The run's other failure is unrelated

release-target (aarch64-unknown-linux-musl) also went red in the same run, on integration_tests::step_promote::test_promote_bare_repo_with_worktrees — a one-off filesystem anomaly during that test's plain-git setup, unrelated to this change. Diagnosis in #3918.