Plugin updates: versioned install + atomic swap + drain + rollback retention

[tayebmokni]

Summary

Update flow: install-of-new-version then atomic swap. New version sits next to old under plugins/{slug}/{version}/, the current symlink retargets, in-flight WASM invocations drain (up to 5s) then the old module is closed and the new one instantiated. Old versions retained for N days (default 30) for rollback then GCd. ABI breaks (abi_version change) do NOT auto-update.

Design reference

• docs/02-plugin-system.md §3.4

Acceptance criteria

• Update(slug, newBundle) flow: verify + pre-compile, write to plugins/{slug}/{newVersion}/, run migrations from last-applied to new latest, atomically retarget current symlink
• Drain: stop accepting new dispatches for old Module, wait up to 5s for in-flight, then force-close
• Pool swap: new Module instantiated, pool pointer atomically swapped, old CompiledModule retained (in-memory) until retention window expires
• Old version retained on disk under plugins/{slug}/{oldVersion}/ for N days (default 30, configurable). GC sweep job removes after.
• Downgrade flow same as update but reverse; refuses if down-migrations from current to target version do not exist
• ABI break (abi_version change between old and new) refuses auto-update; admin must explicitly opt-in per-plugin
• Old ABI continues to be supported for 18 months after a new ABI ships (host advertises supported ABI list)
• Tests: update happy path with in-flight requests; downgrade refused without down migrations; ABI break refused without explicit opt-in; rollback restores prior version cleanly

Dependencies

#45 (lifecycle), #53 (migrations)

Complexity

L