v0.10.5

Fixed

• Plugins you enabled stay enabled across a restart. Every restart of the gateway — an upgrade, a
  host reboot, a container restart policy — silently switched off every extension plugin, with nothing
  written to the log and nothing shown in the dashboard. An integration such as the Chatwoot adapter
  simply stopped relaying until someone noticed and turned it back on by hand. Your enable decision is
  now remembered separately from whether the plugin happens to be running, and the plugins you had
  enabled are started again once the gateway has finished coming up. A plugin that fails to start is
  logged and left disabled rather than holding up the gateway. Enabling still runs the plugin's full
  lifecycle, and a plugin you disabled stays disabled. Nothing to do on upgrade: a plugin that is
  enabled when you upgrade is carried over automatically (#856).
• Messages handled by a plugin are no longer missing from your history. When an auto-reply plugin
  answered a message, it told the gateway to stop passing that message to the remaining plugins — and
  the gateway took that as a cue to forget the message entirely. It was never saved, never sent to your
  webhooks, and never appeared in the dashboard. A chat handled by a bot therefore read as a series of
  replies answering nothing, and any integration downstream never learned the customer had written. The
  same applied to outgoing messages. Stopping the plugin chain now does exactly that and nothing more:
  the message is recorded and delivered to webhooks as usual. Plugin authors: this is a behaviour change
  if you relied on it to hide messages — see 19 — Plugin Architecture.
• A plugin configuration that fails to save no longer reports success. The dashboard showed "Saved"
  and closed the dialog even when the gateway had rejected the change, so the edit appeared to have been
  applied and was silently gone the next time the dialog was opened. The failure and its reason are now
  shown. The same fix applies to a plugin that fails to disable, which previously reported nothing at
  all.
• A plugin that ships its own settings editor no longer shows two editors at once. When a plugin
  provided a custom editor, the dashboard rendered the generated form underneath it as well — so every
  field appeared twice, followed by a second Save button that behaved differently from the editor's own.
  The Chat Flow settings dialog was the visible case. A plugin's own editor now replaces the generated
  form and owns saving; plugins without one are unchanged, form and Save button included.
• A plugin's own settings editor follows the dashboard theme. The editor runs in a sandboxed frame
  that cannot see the dashboard's theme, so it had no way to match it and stayed light — a bright panel
  in the middle of a dark dialog. The dashboard now tells the editor which theme is in use. Plugin
  authors: the theme arrives with the existing settings handshake and can be ignored safely; see
  19 — Plugin Architecture for the contract.
• The chat list no longer shows a stray 0 next to every conversation. Each row in the Chats
  sidebar rendered a literal 0 where the last message's time belongs, on every chat. A conversation
  with no messages reports a timestamp of zero, and the check that was meant to hide the time in that
  case ended up displaying the zero itself. The time is now simply omitted when there is no last
  message, as intended. The unread-count badge was unaffected.
• The login screen shows the gateway's actual version again. The dashboard resolved its version
  from whichever package.json sat in the working directory the build ran from, which meant
  dashboard/package.json — a file a release never touches — rather than the root package.json that
  a release bumps. The two had drifted, so the login screen advertised an older version than the
  gateway was running. Everywhere else in the dashboard hid this, because the sidebar replaces the
  build-time value with the live version from the API once you are signed in; the login screen has no
  session yet and shows the constant as-is. The version is now resolved relative to the build config
  itself, so it no longer depends on where the build was started from.
• A message send that is retried after a recipient-address change is now recorded in the log. When
  whatsapp-web.js reports that a contact's cached address is stale, the gateway re-resolves the address
  and sends again. That retry was silent, so in the case where the engine reports a failure for a
  message it had in fact already delivered, the resulting second copy appeared nowhere in the logs and
  could only be noticed on the recipient's phone. The retry now logs a warning naming the chat and both
  addresses. Sending behaviour is unchanged.

Changed

• A release image is only tagged after it has been proven to start. The release workflow
  published X.Y.Z, X.Y and latest in the same step that built the image, and only then ran
  the boot smoke test — so an image that could not start was already pullable by the time the
  test that catches it failed, which is exactly what happened with 0.10.3. The build now
  publishes a throwaway smoke-<run-id> tag, the smoke test boots that on both architectures,
  and a new promote step re-points the release tags at the identical manifest (no rebuild, so
  provenance and SBOM attestations carry over) only once it passes. The GitHub Release depends
  on the promote step, and the staging tag is cleaned up afterwards.
• The smoke test no longer starts containers with --rm, so a container that exits on its own
  survives long enough for docker logs to report why. The 0.10.3 failure reported
  "No such container" instead of the actual error.