Add "upgrade from store" to installed plugin menu

[EmilyRagan]

Goal

A user can upgrade a plugin to a newer version available on the OpenC3 Store without leaving COSMOS or dealing with files. This is not meant to be much more than MVP, it is meant to address the current hole in the usage of the Store from within COSMOS.

Details

• Action menu on an installed plugin should change "Upgrade" to "Upgrade from file"
  • question: should this be present on plugins installed from the store?
• Action menu on an installed plugin should have new "Upgrade from Store" option
  • (stretch) this item should potentially only be present if the plugin was installed from the Store
• "Upgrade from Store" should query the store for newer versions of the plugin with the same id
  • id for installed plugin should be stored in Redis; if not available at this time, fall back to matching gem filename excluding version number and add another issue to store the id and
• Dialog should open for user to confirm upgrade
  • if multiple newer versions are available, offer a dialog with a drop down to select version (stretch: show minimum COSMOS Version associated with each plugin version)
• Confirming should upgrade the plugin to the selected version
• Cancelling should not upgrade the plugin

[crawlchat]

Findings from the codebase (click to expand)

• The plugin action menu lives in PluginListItem.vue . The "Upgrade" item (line ~68) just emits upgrade, which the parent handles by opening a file picker — this is the item to rename to "Upgrade from file".
• Store metadata is already modeled via PluginProps.js , which defines id, versions, current_version_id, minimum_cosmos_version, gem_url, checksum, etc. — these are populated for cards in PluginStore.vue, so the Store API already returns a per-plugin versions list (good news for the "select version" dropdown, since it looks like this data model may already support surfacing minimum_cosmos_version, though I didn't confirm whether each entry in versions carries its own minimum_cosmos_version or just the top-level one).
• openc3/lib/openc3/models/plugin_model.rb has a section around line 241 explicitly commented "Process OpenC3 Store metadata" — this looks like the most likely existing hook for persisting store-origin info (id, etc.) on install. I ran out of tool budget before reading that block in full, so I can't yet confirm whether the store plugin id is already saved on the installed PluginModel, or whether that's still a gap.

Answering the embedded question

Should "Upgrade from file" remain visible on plugins installed from the Store?

Yes — keep it. Users may want to install a locally-modified/forked gem even for a Store-origin plugin (e.g., a hotfix before it's published), and hiding it removes a valid escape hatch. Just make "Upgrade from Store" a second, additional item rather than a replacement.

Suggested approach

1. UI (PluginListItem.vue): rename title="Upgrade" → "Upgrade from file" (keep @click="upgrade" file-picker flow). Add a new v-list-item title="Upgrade from Store" that only renders when the plugin has store metadata (i.e., a resolvable id), satisfying the stretch goal naturally rather than needing extra state.
2. ID resolution: Confirm whether PluginModel/plugin_model.rb already persists the store id at install time (the "Process OpenC3 Store metadata" block looked promising). If not present, fall back to matching by gem base name (stripping the version segment, same regex pattern already used in displayTitle in PluginListItem.vue line ~183) and file a follow-up issue to persist the real id in Redis going forward.
3. Version query + dialog: reuse the existing versions/current_version_id shape from PluginProps.js to build a simple confirm dialog; only show the version <v-select> when more than one newer version exists.
4. Confirm/cancel: confirm triggers the existing store-install pipeline pointed at the selected version's gem_url; cancel just closes the dialog with no side effects.

What I couldn't verify (please confirm before implementing)

• Whether plugin_model.rb's "Process OpenC3 Store metadata" block already stores the store plugin id in Redis today, or whether that's genuinely new work.
• Whether each entry in the versions array from the Store API includes its own minimum_cosmos_version, or only the plugin-level field.

If someone can confirm those two points, I'm confident this is a straightforward, scoped MVP change.