Feature Request: Full Library Discovery API

Problem: There is currently no Plugin API to enumerate all connected/enabled libraries of a file, nor to list the styles (paint, text, effect) published by a connected library. The only library discovery surface is teamLibrary.getAvailableLibraryVariableCollectionsAsync(), which returns variable collections but nothing about styles.

Current workarounds and why they fail:

1. Scanning the document for remote style IDs — You can walk every node across all pages, collect fillStyleId, strokeStyleId, textStyleId, effectStyleId, check style.remote, and group by the file key embedded in the style ID (S:<fileKey>,…). This is extremely slow on large files (thousands of nodes across many pages), incomplete (only finds styles actually in use, not the full library), and fragile (relies on internal ID format for grouping).

2. getAvailableLibraryVariableCollectionsAsync() — Returns LibraryVariableCollection[] with libraryName, which lets you discover library names and their variable collections. But there's no equivalent for styles — no getAvailableLibraryStyleCollectionsAsync() or similar.

3. importStyleByKeyAsync(key) — Can import a single style if you already know its key, but there's no way to discover what keys exist in a library.

What would help (in priority order):

1. teamLibrary.getAvailableLibrariesAsync() — Returns all connected libraries with metadata: { name, key, fileKey, hasVariables, hasStyles }. This is the biggest gap — just knowing what's connected.

2. teamLibrary.getStylesInLibraryAsync(libraryKey) — Enumerate all published styles (paint, text, effect) from a connected library, analogous to getVariablesInLibraryCollectionAsync() for variables. Return { name, key, type } at minimum.

3. Style collection grouping — If libraries organize styles into collections/groups, expose that hierarchy the way variable collections are exposed.

Use case: Style remapping tools that let users migrate designs from one design system to another. The target library's full catalog of styles and variables needs to be enumerable so the tool can match source styles to target equivalents — without requiring every target style to already be in use somewhere in the document.