CI and RELEASE workflows should support "auto-discovery" of plugins

## What

Extend the CI and RELEASE GitHub Actions workflows to support "auto-discovery" of plugins under the plugins directory instead of being hard-coded to code-editor-plugin.

Today both workflows only work for the code editor plugin:
- CI only triggers on changes under `plugins/code-editor-plugin/**` and runs with `working-directory: plugins/code-editor-plugin`.
- RELEASE only triggers for tags matching `code-editor-plugin/v*`, reads version from package.json, and produces code-editor-plugin-specific artifact names and release titles.

A useful extension would be to discover plugin directories automatically and build/release them without needing to duplicate or hard-code workflow logic for each new plugin.

## Why

The current workflow design does not scale beyond a single plugin. Any new plugin added under plugins would require manual workflow changes for:
- trigger paths
- working directory selection
- dependency cache paths
- package version lookup
- tag naming
- artifact naming
- release title generation

Auto-discovery would make the repository easier to grow, reduce workflow maintenance, and help ensure new plugins can participate in CI and release automation through a shared convention instead of one-off workflow edits.

Locate the CI and RELEASE GitHub Actions workflow definitions and inspect how they reference plugins/code-editor-plugin, working directories, package.json, tags, caches, artifacts, and release titles. Then define a shared convention for discovering plugin directories and verify that each discovered plugin can trigger CI and produce the expected release outputs without hard-coded plugin names.

Written by the indexing model from the issue text.