#3370 Registry scorer: a deno doc failure discards the whole scorecard, including the LICENSE and README facts (12 public extensions unscored)

Problem

When deno doc fails on an extension, the registry's scorer throws away the whole scoring run. That includes facts that don't depend on deno doc: the LICENSE file, the README and the description. The extension then has no scorecard at all (available: false, reason: "failed"), Rescore can't fix it, and #3323's hiding treats it as unknown.

DenoDocExtensionTarballAnalyzer.analyze (lib/infrastructure/extension-tarball-analyzer.ts) computes hasLicenseFile and readme first, then calls runDenoDocJson. When that throws, process-extension-scoring-event.ts logs "Extension scoring analysis failed" and no version meta is written.

Evidence (production, 2026-10-13)

12 public extensions fail every time, even after a manual Rescore. Reproduced locally by running the analyzer on their latest archives:

Change

• A deno doc failure doesn't abort scoring. Record hasLicenseFile, the README factors, the description, platforms and dependency trust as usual.
• Score the doc-dependent factors as failed, with a short, author-readable reason: which import failed to resolve, with paths redacted as today.
• Show that reason on the scorecard so the author knows what to fix.
• Hiding uses the recorded hasLicenseFile. The 6 with a LICENSE file become licensed and listed. The 6 without become correctly hidden.
• Rescore all 12 after deploy, and confirm each has a scorecard.

Acceptance

• Unit tests: a bare-specifier archive and a missing-relative-module archive each produce a scorecard, with license and readme factors set and doc factors failed with the reason.
• Production: all 12 have a scorecard after the rescore. The 6 with a LICENSE file are listed, and the 6 without are hidden.

Related

• #3342 (Rescore scores the newest version, not the scorecard version) is in the same scoring path; do it next, in sequence.
• #3326 is in flight in swamp-club and touches the has-license factor.