A playground nobody can open is a file, not a deliverable

The playground gate required a directory with HTML in it and the word "playground" somewhere in the PR body. Both were satisfiable while the reviewer still had nothing to click, because GitHub does not render HTML from a repository. The advice that would have fixed it already existed, but only inside the failure text of a check that passes the moment the body contains that word.

Can you actually open it?

Pick how a PR references its playground and see whether a reviewer can view the page.

What the gate now checks

step	asks	new
Decide whether required	is any changed file non-inert
Check playground exists	does docs/<branch-slug>/ hold HTML
Published to the Lab	is every one of those files a `source` in lab-manifest.json	yes
Link in PR body	does the body mention a playground

The new step only inspects the current branch's own directory, so the 249 historical playgrounds already on main are untouched. It does mean the Lab grows by one entry per playground-bearing PR from now on, which changes it from a curated set of 23 into a growing archive.

Two smaller repairs in the same file

The body check used echo "$PR_BODY" | grep -qi. Under pipefail, grep -q exits on the first match and SIGPIPEs the producer, whose 141 then propagates and flips the enclosing test non-deterministically. This repo already fixed that exact shape one step earlier in the same job, with a here-string. Now both match.

The new step keeps its Python to a single line. An unindented heredoc inside a run: | block terminates the YAML block scalar, which breaks the entire workflow rather than the one step. That is not hypothetical: the first draft of this change did it, and the file stopped parsing.