An icon, a Check again that checks, and the auto-update rule written down

Three gaps found by being asked plain questions about it.

**The auto-update toggle was a promise nobody had checked.** offer_update()
answers even when the installed version is current, on the reasoning that the
answer has to land in WordPress's no_update list for the "Enable auto-updates"
link to exist at all. That was a comment and an intention; it is now an
assertion against the real WP_Plugins_List_Table, which is where the flag is
actually read:

    $plugin_data = array_merge( (array) $plugin_info->no_update[ $plugin_file ],
                               array( 'update-supported' => true ), $plugin_data );

A plugin in neither response nor no_update gets "Auto-updates are not available
for this plugin" while looking entirely healthy.

**An icon.** Without one, Dashboard → Updates shows a generic grey plug.
assets/icon.svg, handed over in the offer's icons key, served from the shop's
own copy rather than the release host — one fewer thing that must be reachable
for wp-admin to render, and it cannot go mixed content on an HTTPS shop. Drawn
as paths rather than <text>: an SVG that leans on a font renders differently on
every machine, and this one is shown at about 40px, which is the size where
that is the difference between a mark and a smudge.

**"Check again" now checks again.** The six-hour cache is right for the check
WordPress runs twice a day and wrong for a link whose whole promise is that it
looks now. Publishing a release and then clicking it showed nothing for up to
six hours, which reads exactly like a broken updater.

And docs/REUSE.md was missing all of this: it covered Update URI, where to
instantiate the updater and making the repo public, but not the one rule that
is genuinely easy to get wrong.

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

docs/REUSE.md

@@ -52,6 +52,31 @@ and instantiate the updater **before** any "is WooCommerce active" gate — a
 shop with WooCommerce switched off for an afternoon must not quietly stop
 receiving fixes.
 
+Three things in that file are load-bearing and none of them look it:
+
+- 🔴 **`offer_update()` answers even when the installed version is already
+  current.** It is tempting to return `false` there — there is no update, after
+  all — and that one line is what silently removes the **Enable auto-updates**
+  link from the Plugins screen. `WP_Plugins_List_Table` sets
+  `update-supported` only for plugins it finds in the update transient's
+  `response` **or** `no_update` list; a plugin that stays silent is in neither,
+  and wp-admin says "Auto-updates are not available for this plugin." The
+  plugin looks perfectly configured and can never auto-update.
+  `tests/smoke.php` asserts the rendered table, not the intention.
+- **Set `icons`.** Without it Dashboard → Updates shows a generic grey plug.
+  Point it at the shop's own copy (`PLUGIN_URL . 'assets/icon.svg'`), not the
+  release host: one fewer thing that must be reachable for wp-admin to render,
+  and it cannot go mixed-content on an HTTPS shop.
+- **`Update URI` also switches wordpress.org off** for this plugin, from
+  WordPress 5.8. Remove the header and a .org plugin that happens to share the
+  slug could be pushed onto a shop running yours.
+
+The answer is cached for six hours, which is right for the check WordPress runs
+twice a day and wrong for the **Check again** link — so `forget_on_force_check()`
+drops the cache on `force-check`. Without it, someone who has just published a
+release clicks that link, sees nothing, and concludes the whole mechanism is
+broken.
+
 **6. Make the Gitea repository public**, or point `Update URI` at a separate
 public releases-only repository. Every shop reads that feed without
 credentials; `ci/publish-release.sh` fails the release with this instruction if
@@ -74,6 +99,9 @@ it cannot.
   credentials to prove a shop can download it.
 - `ci/update-smoke.sh` — install the previous version into a throwaway shop and
   let WordPress update it by itself. The only check that proves the whole chain.
+- Assertions that the **Enable auto-updates** link is actually offered, built
+  from the real `WP_Plugins_List_Table`, and that the update offer carries an
+  icon that exists in the release.
 - `ci/workflows-in-sync.sh` — fails when the two workflow roots drift, which is
   the only way to notice that a workflow stopped running on Gitea.