Auto-update installed themes and plugins

[compscidr]

Came out of #640: goblog 0.12.0 changed how GitHub login works, an older theme could not complete it, and the admin needed a login to fix the theme. #640 recovers from that particular mismatch. Auto-updating would stop the class of it.

Why it fits here

Most of the machinery exists:

• both installers already have Update(ctx, name)
• Status().Installed already carries UpdateAvailable and LatestVersion
• downloads are verified against the index's content hash, and the theme installer parses the templates before anything is written

So the core is close to "for each installed item with an update available, call Update".

Blocker: UpdateAvailable ignores compatibility

// theme/installer/installer.go
row.UpdateAvailable = row.Version != "" && pinstaller.Newer(e.Version, row.Version)

It checks only that the directory's version is newer — not that it is compatible. Update() then calls lookup(), which refuses with ErrIncompatible.

Today that means the admin page offers updates it will not apply. For an auto-updater it means attempting and failing on every boot. Compatible(i.Version, e.MinGoblogVersion) needs to be part of the flag, and the plugin installer wants the same check. Worth fixing on its own even if the rest waits.

Decisions this needs

1. On by default, or opt-in? Unattended changes to a live site cut both ways: the same property that patches a site quietly also changes it quietly.
2. Themes only, or plugins too? A theme is templates and CSS. A plugin is executing code — WASM or dynamic — which is a materially larger trust step, even from a hash-verified directory. Themes on by default and plugins opt-in is the obvious split, but worth arguing.
3. When? At startup is what would have prevented Restart the login when a callback carries no state at all #640's trap. A periodic check is what keeps a long-running site patched. Probably both, with the periodic one off by default.
4. Failure handling. The directory being unreachable at boot must never block startup or wedge the site. A theme that fails to parse must leave the old one in place — fetchAndCheck already validates before place, so this may hold already; worth a test that says so.
5. Visibility. An admin should be able to see that something changed under them: at minimum a log line, ideally a note on the themes/plugins page.

Note

Worth being deliberate about (1) and (2) rather than picking the convenient default. Auto-update is the one feature where the failure mode is "every site broke at once", so whatever ships should be easy to turn off and loud about what it did.