## Description Migrate components from Options API to Composition API (`<script setup>`). The codebase is on Vue 3 with `@vue/compat`; once the compat shim is removed (#730), this is the natural next step toward idiomatic Vue 3. ## Background The bulk of the codebase uses Options API patterns: `mapGetters`/`mapState`/`mapMutations`/`mapActions`, `data()`, `computed`, `methods`, `mounted` etc. These work fine but Composition API offers better TypeScript integration, easier logic reuse via composables, and clearer dependency relationships. ## Approach - Migrate incrementally — one component or domain at a time - Prefer `<script setup>` syntax - Extract repeated logic into composables under `src/composables/` - Keep Vuex 4 store access via `useStore()` during migration; evaluate Pinia as a separate initiative - Each migrated component must have its existing tests passing (update test style where needed) ## Suggested order 1. Leaf components first (no children, minimal store deps) 2. Shared UI components (`src/core/components/`) 3. Domain stores and their primary consumers 4. Complex orchestrators (e.g. Scene.vue — see also #scene-decomp) ## Acceptance Criteria - All migrated components use `<script setup>` - No regressions in existing test suite - No Vue compat warnings introduced ## Related - Blocked by: #730 (@vue/compat removal) - See also: #15 (superseded TypeScript migration — TypeScript coverage is tracked separately)