publishing a plugin is pushing a tag

Three mechanisms where there should be one. The catalogue was filled by hand, and each host separately
polled twenty-one repositories with git to work out whether a release existed — a second source of
truth for a fact one place already knew. Shipping photos 2026.09.03.02 correctly and watching alpha
not notice for ten minutes is what started this.

The timer. scripts/marketplace-cron.sh, every minute, on the machine that publishes. Safe now only
because the previous commit made the sync read tags instead of working trees; over the old one this
would have published somebody's afternoon on a schedule. Nothing is written unless the release commit
differs from the one already published, so a tick with nothing to do is one query, one fetch per repo
and no writes — about 2.7s. One timestamped summary line per tick regardless, because a fresh timestamp
is the only thing that separates "nothing to publish" from "the timer died"; a named line only for a
plugin that moved.

The badge. `updateable` now compares the tag at HEAD with the tag the catalogue says is newest —
difference, not ordering, since parsing 2026.08.27.01 works right up until somebody tags v2 and then
fails silently. refreshRemote() and its two-minute window are gone with the polling they existed to
paper over. The git rule stays as the fallback for a plugin the store cannot speak for: an unregistered
checkout, or an unreachable store. That case now reads whatever refs the last pull left, which is the
accepted cost of not making every machine poll every repository forever.

fetchCatalogue()'s cache went from five minutes to one. It only drew tiles before; now the wait for a
release to appear would have been the sync's minute plus its five.

Also: the Update button names its destination whenever a release is known, not only on `new-release`.
An untagged checkout reports `untagged` and used to lose the tag with it, so the button said "Update"
and the owner had to guess where it landed — the marketplace knows, even for a checkout that has never
fetched it.

Verified: forced a stale row, the timer republished it inside 60s and logged one line. Badge decisions
checked against the live catalogue for seven plugins, including the two shapes that matter — at a tag
the store agrees with, and untagged with a release known only to the store. 9 release tests pass, 100%
of release.ts covered, four of them new and all against real repositories.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/databases/marketplace_db/src/plugins/queries.ts

@@ -115,6 +115,14 @@ export async function catalogueEntry(appName: string): Promise<CatalogueEntry |
   return { ...entry, ...(row.metadata.readme ? { readme: row.metadata.readme } : {}) };
 }
 
+/**
+ * A registry row, plus the one piece of metadata the sync needs before deciding to do any work.
+ *
+ * `sourceCommit` is what the last sync published, and it is here rather than fetched per plugin so a
+ * run that has nothing to do costs one query instead of twenty-five. Null means never synced.
+ */
+export type RegistryRow = { id: number; appName: string; repoUrl: string; sourceCommit: string | null };
+
 /**
  * Every registered plugin — identity and clone URL, no metadata.
  *
@@ -124,10 +132,16 @@ export async function catalogueEntry(appName: string): Promise<CatalogueEntry |
  * same as no longer tracking it, and one taken down for a bad release has to be able to come back
  * current.
  */
-export async function listRegistry(): Promise<{ id: number; appName: string; repoUrl: string }[]> {
+export async function listRegistry(): Promise<RegistryRow[]> {
   return marketplaceDb
-    .select({ id: plugins.id, appName: plugins.appName, repoUrl: plugins.repoUrl })
+    .select({
+      id: plugins.id,
+      appName: plugins.appName,
+      repoUrl: plugins.repoUrl,
+      sourceCommit: pluginMetadata.sourceCommit,
+    })
     .from(plugins)
+    .leftJoin(pluginMetadata, eq(pluginMetadata.pluginId, plugins.id))
     .orderBy(plugins.appName);
 }