🐛 Upgrade staticalize to 0.3.0 so the sitemap is valid

[taras]

Motivation

Every sitemap this site has deployed is invalid. Staticalize wraps each <loc>
in <urls> rather than <url>, which is not the
sitemaps.org schema, so crawlers are
handed a document whose entries they have no reason to understand.

It went unnoticed because staticalize's own reader accepts either spelling
(xml.urlset.url ?? xml.urlset.urls), so a site staticalized twice round-trips
its own invalid output. thefrontside/staticalize#14 has the details;
thefrontside/staticalize#15 fixes the writer, and 0.3.0 is the first release
that carries it.

One of four sites in the org on an affected version — see the table at the
bottom.

Approach

• www/deno.json — the staticalize task moves from 0.2.2 to 0.3.0
• .github/workflows/www.yaml — the downloaded binary moves from v0.2.6 to
  v0.3.0, in both the preview and the production job

0.3.0 requires --retries, where 0.2.x applied a documented default of 3.
Neither the task nor the workflow passed it, so both would have started failing
outright on the new version:

retries: Invalid input: expected number, received undefined

They now pass --retries=3, which is the value they were already getting. That
requirement is itself a bug (thefrontside/staticalize#19), already fixed by
thefrontside/staticalize#20 but not yet released — once it ships, the flag can
come back out.

The "@frontside/staticalize" import map entry is removed rather than bumped.
Nothing imports that specifier — the task names the full jsr: url — and it was
the only thing pinning the package in deno.lock, so bumping it would have
pulled staticalize's entire 0.3.0 dependency tree into the lock for no reason.
Dropping it is a one-line lock change instead of 183.

Two other fixes ride along in 0.3.0, neither of which changes anything here:

• the path component of --base is honoured — this site's base is
  https://interactors.netlify.app, which has no path
• self-referencing urls are rewritten outside HTML as well, not only inside it

And it says where it lives

Second commit, which the upgrade is a prerequisite for.

The deploy staticalized with --base=https://interactors.netlify.app, so every
page told Google the canonical copy was the Netlify one:

frontside.com/interactors/docs/quick-start
  <link rel="canonical" href="https://interactors.netlify.app/docs/quick-start">

frontside.com proxies this site and serves the same pages, so the two origins
are duplicates of each other and the canonical points at the copy nobody links
to — the page frontside.com serves disclaims its own content. The base is now
the url readers actually visit.

useAbsoluteUrl already builds the canonical from the crawl origin, so
staticalize rewrites it along with og:url and every internal link. 0.3.0 is
what honours the path component of --base, which is why this cannot go
ahead of the upgrade.

thefrontside/effection#1248 did the same for Effection.

Tests

Served a two-page site with a valid sitemap and staticalized it with both
versions:

0.2.x, what this site runs today

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <urls>
    <loc>https://example.com/</loc>
  </urls>
</urlset>

0.3.0, this PR

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
  </url>
</urlset>

Staticalized this site locally against the new base and read the output:

<link rel="canonical" href="https://frontside.com/interactors/docs/quick-start">
<meta property="og:url" content="https://frontside.com/interactors/docs/quick-start">
href="https://frontside.com/interactors/docs/quick-start"

sitemap: 73 entries, all https://frontside.com/interactors/..., spelled <url>

And confirmed frontside.com mounts that sitemap without doubling the prefix,
using the function from thefrontside/frontside.com#509:

/interactors/                  -> /interactors/
/interactors/docs/quick-start  -> /interactors/docs/quick-start

I also checked that --site still works, since 0.3.0's --help now presents the
site as a positional argument. It does; no caller needs changing.

A note on the lockfile

deno install --frozen fails on this branch. It fails identically on main
without these changes, so the lock was already stale and I left that alone
rather than folding an unrelated regeneration into this PR.

Other sites that need the same bump

repo	local task	CI binary	status
thefrontside/frontside.com	0.2.6 → 0.3.0	v0.2.7 → v0.3.0	thefrontside/frontside.com#508
thefrontside/interactors	0.2.2 → 0.3.0	v0.2.6 → v0.3.0	this PR
thefrontside/graphgen	0.2.6 → 0.3.0	runs the task	PR open — still advertises its own origin, and emits no canonical at all
thefrontside/effection	0.2.2 → 0.3.0	v0.2.6 → v0.3.0	thefrontside/effection#1248

Merge order

thefrontside/frontside.com#509 must land first. Until it does, frontside.com
prefixes /interactors onto sitemap entries that already carry it, and a
sitemap published under the new base would break its deploy the way Effection's
did.

[github-actions]

Package Changes Through 7e5bed7

There are 1 changes which include @interactors/core with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
@interactors/core	1.0.1	1.0.2
@interactors/keyboard	1.0.1	1.0.2
@interactors/html	1.0.1	1.0.2
@interactors/material-ui	5.0.0	5.0.1

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[github-actions]

🚀 Deploy Preview Ready!

• Stable Review Link: https://pr-332--interactors.netlify.app
• Latest Commit Snapshot: https://6aba0f45bb2c689ccae79c53--interactors.netlify.app