Create sustainable extension API v2 with import-based versioning and compatibility layer

## The Future of the Public Extension API

## Current API Surface

The extension API is fragmented across seven locations:

1. **Lifecycle hooks** (`app.ts`) - https://docs.comfy.org/custom-nodes/js/javascript_hooks
2. **App properties** (`comfyApp` object, often getter/setter wrapped)
3. **Node prototypes** (node objects and LiteGraph properties)
4. **Canvas methods** (LGraphCanvas class)
5. **API layer** (`api.ts` methods and events)
6. **DOM events** (LiteGraph canvas/window events)
7. **UI controls** (Vue layer, registration systems via workspaceStore.ts)

## V2 API Design

### Import-Based Versioning
Extensions will explicitly import API versions (`extensionManager_v2`) for better type resolution and simpler compatibility mapping.

### Sustainability Principles
- **Method-based access** - eliminate direct object exposure
- **Prototype isolation** - prevent monkey-patching
- **Immutable data** - read-only access to definitions
- **Signals-driven subscriptions** - replace direct method overrides or callback properties
- **Gateway pattern** - single access point with interface segregation

## Implementation Tasks

**API Infrastructure:**
- [ ] Build compatibility wrapper with import-based versioning ([prototype](https://github.com/Comfy-Org/ComfyUI_frontend/tree/feat/import-based-api-versioning))

**Service Migration:**
- [ ] Move app/api methods (items 1,2,5) to extension service with v1 backward mapping
- [ ] Split LiteGraph concerns (items 3,6) into renderer/graph services (future scope) then expose through those services' interfaces -> extension service

**Prototype Elimination:**
- [x] Audit current prototype usage ([report](https://file.notion.so/f/f/54cc0cde-b5c6-44cc-9e1c-6d0a4b1f40bc/6caf7166-afee-41a9-af9c-9c60d9762d47/report.md))
- [ ] Implement v2 methods covering 50%+ of prototype use cases
- [ ] Remove prototype access in v2, add v1 deprecation warnings

**Documentation:**
- [ ] Add deprecation warnings to v1 compatibility methods
- [ ] Update docs with v2 migration paths

## Additional Possible Ideas

1. **Phased rollout** - Consider releasing v2 incrementally by service rather than all at once
2. **Breaking change budget** - Define acceptable compatibility boundaries (e.g., maintain 80% of current usage)
3. **Extension telemetry** - Track v1 API usage to prioritize v2 method implementation
4. **Developer preview** - Beta test v2 with major extension authors before general release
5. **Migration tooling** - Provide codemods or linting rules to automate common v1→v2 transitions

┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-4668-Consolidate-Public-Extension-hooks-functions-in-extension-service-2446d73d36508198830bd38d9094d7a6) by [Unito](https://www.unito.io)