Community catalog: what counts as "bundled output with the source in the repository" for an inlined third-party library?

[Pr1p]

What we are trying to do. pr1p/orca-mermaid-editor is a custom-editor plugin that renders and edits Mermaid diagrams. It needs a rendering library, and the plugin frame's CSP allows inline scripts only (script-src 'unsafe-inline'), so the library has to be embedded in editor/index.html — an external <script src> is blocked.

What the automated catalog check has said.

tag	verdict
v0.2.0	rejected — code, size
v0.3.0	rejected — code, size
v0.3.1	rejected — code

Between v0.3.0 and v0.3.1 we removed a stale 2.57 MB vendored file the build no longer read, which cleared size: the inlined bundle is now 1.23 MB, below the inlined editors that other listed viewer plugins ship.

What the plugin now provides for provenance.

• build-trim/build-trimmed.mjs plus package.json/package-lock.json pinning mermaid 11.4.1 and esbuild, so the bundle is reproducible from the repository;
• THIRD_PARTY_NOTICES.txt with the MIT texts, versions and upstream links (mermaid, esbuild, and the transitive licenses resolved by the lockfile);
• a README section documenting that the bundle is generated, not hand-written.

Why we cannot simply unminify. The same trimmed bundle is 2.72 MB unminified, which is larger than the 2.58 MB that failed size in v0.3.0, and vendoring mermaid's full source would be tens of MB. So "ship the source next to the bundle" and "ship unminified output" both lose to the size gate.

Questions.

1. What form does the automated code check accept for a third-party library that must be inlined? For example: unminified output, a source archive under vendor/, a source map, or an allowlist for pinned packages?
2. Some listed viewer plugins ship a 1.4–1.5 MB inlined editor/index.html with their build sources in the repo. Is that the distinguishing factor, or did those plugins pass a different check?
3. If a minified inline bundle is not acceptable regardless of pinned provenance, is a viewer plugin that needs a rendering library in scope for the catalog at all?

We are not asking to be listed as an exception — we would rather learn the rule, comply, or stop spending the check's cycles. If the answer is "this shape is not supported", that is fine: the plugin already works installed from its Git URL, and we will drop the catalog request.

Thanks.