[markafoltz]

This PR replaces the generic PR preview workflow with a custom version that works with our repository. It handles multiple specifications, bundling images, and preprocessing the CDDL files to generate HTML and HTML diffs when a spec PR is pushed.

The artifacts are hosted in temporary pr-preview/pr-<N>/ folders in the gh-pages branch. The folders are removed when a PR is closed.

We could move the PR preview hosting to another repository or cloud service but it's more overhead.

[backkem]

Thanks, previews for all specs will help. Two concerns, and some options:

Problems

1. Security: fork PRs control the uploaded artifacts (they can edit auto-publish.yml in their own PR), and this workflow publishes them with a write token to w3c.github.io, which every w3c repo's published specs share. The external PR Preview service avoids this by building from source itself and hosting on a separate, throwaway origin (pr-preview.s3.amazonaws.com).
2. Race: on merge, the cleanup job and the main spec-prod deploy push gh-pages at the same time, and spec-prod's --force-with-lease push can fail. A shared concurrency: gh-pages group (push runs only in auto-publish) avoids that.

Options for point 1:

• Gate this workflow: deploy only for same-repo PRs (workflow_run.head_repository.full_name == github.repository), or for collaborators or a maintainer label. It's the smallest change.
• Host custom previews on a separate origin: an S3 bucket, Netlify, or Pages under a different org (not w3c.github.io). It's safe for forks, at the cost of setup and a secret.
• Go back to the standard service: render the CDDL preprocessing before committing, so each .bs builds on its own, with a CI lint checking that the rendered output is up to date. Then PR Preview could build network.bs and application.bs directly, if .pr-preview.json can list more than one spec.

I think the latter could be a safe/simple/pragmatic solution. We could add a lint to check that the CDDL preprocessing wasn't forgotten.