chore(deps): upgrade dependencies

[github-actions]

Upgrades project dependencies.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[pgollucci]

Root cause of the build failure

Not a CI problem and not the TypeScript 7 break. The culprit is js-yaml 4.1.1 -> 5.2.3.

js-yaml 5.x is ESM-first and no longer ships a default export (only named exports):

js-yaml@4.1.1  ->  "default" in ns === true,  typeof ns.default.load === "function"
js-yaml@5.2.3  ->  "default" in ns === false, ns.default === undefined

Both getStaticProps call sites used a default import, so yaml.load(...) became
undefined.load(...) at prerender time. The real frame out of the compiled chunk:

async function p(){ let a=f.default.join(g.default.cwd(),"content/articles.yml"),
  b=e.default.readFileSync(a,"utf8");
  return{props:{articles:(0,m.parseArticles)(h.default.load(b))}} }

h is the js-yaml namespace; h.default is undefined. Hence
TypeError: Cannot read properties of undefined (reading 'load') on / and /news.

Fix

Switched both call sites to the named load export. This is not a pin or a revert, and it is
version-agnostic: the named load export exists in js-yaml 4.x and 5.x alike, so the change is
safe independent of the bump.

Reproduced locally before the fix (identical error) and verified green after: 6/6 static pages
generated and exported, out/news.html contains real article content.

Why TypeScript did not catch this

tsconfig.json sets allowSyntheticDefaultImports: true, which suppresses exactly this error.
With it off, tsc reports:

src/pages/index.tsx(3,8): error TS1192: Module '.../js-yaml/dist/js-yaml' has no default export.
src/pages/news.tsx(5,8):  error TS1192: Module '.../js-yaml/dist/js-yaml' has no default export.

That flag is load-bearing here for fs/path/react/@next/mdx under
moduleResolution: bundler, so it should not simply be flipped off. Noting it as the reason a
runtime-breaking major landed with a clean Running TypeScript step.

Follow-up, not blocking

@types/js-yaml@4.0.9 is now stale: js-yaml 5 ships its own types, and because the upgrade
action runs pnpm up --latest --prod this devDependency will never be bumped. It is dead
weight today and a latent source of wrong types. Worth removing in a separate change.

[pgollucci]

Blocked on repo config, not on this change

build is green and the PR is CLEAN / MERGEABLE / APPROVED, but it cannot reach MERGED
on its own. auto-queue.yml failed
(run 30830840980):

{"data":{"enqueuePullRequest":null},"errors":[{"type":"UNPROCESSABLE",
  "message":"Merge queues are not enabled for pgollucci/gollucci.com."}]}

Confirmed against the ruleset. Ruleset 12233761 ("default branch") resolves to:

["deletion","required_linear_history","pull_request","required_status_checks","non_fast_forward"]

No merge_queue rule, so enqueuePullRequest can never succeed here. This is not new breakage
from this PR: the previous run on 2026-08-02 reported "success" only because it skipped (the
Build had failed). The gap was masked by the red build and is exposed now that the build is green.

Two other things that fell out of checking the ruleset:

• required_signatures is not enforced on this repo, contrary to expectation. This commit is
  GPG-signed anyway.
• The Mergify Merge Queue / Summary checks are legacy: there is no .mergify.yml or
  .github/mergify.yml in the repo, just the app still installed, which is why the queue check
  reports NEUTRAL. Not required, not blocking.

Resolving this means enabling a merge queue on main in ruleset 12233761, which is a ruleset
change and deliberately out of scope for me. Leaving the decision to @pgollucci.