Support the 0.1.x plugin SDK and fix the pinned window anchor (BigBlueButton 4.0)

[imdt-claudiop]

Why

BigBlueButton 4.0 ships version 0.1.26 of the plugin SDK. The server compares that
version against the requiredSdkVersion declared in the plugin manifest and refuses to
load anything that does not match, so on a 4.0 server this plugin is rejected before its
bundle is ever fetched:

Cannot load plugin [BbbPluginPinMessage]: system SDK version [0.1.26] does not satisfy plugin requirement [~0.0.59].

This is the v0.1.x line, which is the one that targets the 0.1.x SDK, so this makes the plugin load and work on BigBlueButton 4.0.

What changed

• manifest.json: requiredSdkVersion from ~0.0.59 to ^0.1.2
• package.json and package-lock.json: bigbluebutton-html-plugin-sdk from 0.0.73 to 0.1.26
• src/plugin-test/component.tsx: the floating window looked for #chat-list-0 to position itself. That id does not exist in 4.0 any more (it now belongs to a private chat item), so the lookup returned null and the window fell back to its default corner position, on top of the left navigation rail and the chat header. It now looks for #chat-list, which exists in both 3.0 and 4.0.

The plugin version itself was deliberately left alone. It is cut by the publish-tag workflow, which also updates package.json and package-lock.json, so it belongs to the release process rather than to this change.

How to test

1. Build and host the bundle:

   npm ci
   npm run build-bundle
   

   Serve manifest.json and dist/BbbPluginPinMessage.js from a URL the BigBlueButton server can reach. They have to sit next to each other, since javascriptEntrypointUrl is relative.
2. Attach the plugin to a single meeting, so no server side configuration is touched. In API-Mate, add this Create custom parameter:

   pluginManifests=[{"url":"https://<your-host>/<folder>/manifest.json"}]
   

3. Join the meeting as moderator. Send a message in the public chat, hover it and click Pin this message. The floating window appears next to the chat panel.
4. Optionally confirm the server accepted the plugin, in the bbb_graphql database:

   SELECT name, "loadFailureReason" FROM plugin;

   loadFailureReason must be empty for this plugin.

Validation

Checked against a BigBlueButton 4.0 server built from source on v4.0.x-develop at commit 93bc4864ab, shipping plugin SDK 0.1.24, with the plugin attached per meeting:

• npm run lint runs clean locally. npx tsc still reports the pre existing errors described in the notes below, which the base branch reports as well
• the plugin loads with an empty loadFailureReason and the client reports no page error
• message pinned, floating window rendered at top 115 and left 387, which is the top and right edge of the chat list plus the 5px offset the plugin applies

Before and after, same server, same steps. Before, the window sits in the top left corner and covers the navigation rail and the chat header. After, it sits beside the chat panel.

Before	After

Animated preview below, click the GIF to open the MP4 (larger, with controls):

In the video: the message is sent at 00:24, and the pinned window appears beside the chat panel at 00:32.

Re-verified after moving to SDK 0.1.26, on the pushed head: npm ci, npm run lint and npm run build-bundle all run clean, and the lock resolves the SDK to exactly 0.1.26. npx tsc still reports only the pre existing node_modules errors described below.

Notes

• requiredSdkVersion is set to ^0.1.2, so any 0.1.x SDK from 0.1.2 up is accepted. The build pins 0.1.26, the SDK that 4.0 currently ships, while the wider floor also lets the plugin load on 4.0 servers that are still on an earlier 0.1.x SDK. Caret rather than tilde because on a 0.x floor the two operators accept exactly the same versions, and caret is the one that still expresses the intended range once the SDK reaches 1.0.0; note that ^0.1.2 by itself does not admit a 1.0.0 SDK.
• npx tsc reports two errors on type declarations inside node_modules (react-markdown and @types/prop-types). Those are pre existing: the base branch reports them too, plus a third one coming from the older SDK typings, which this change removes. So this is one error fewer than before, and the two that remain are untouched pre existing debt.

Co-authored with Guilherme Leme, who created the v0.1.x branches for these plugins.

[imdt-claudiop]

Pushed a small tsconfig.json commit turning on skipLibCheck, so this branch's own ts-code-compilation gate goes green.

The gate runs npx tsc, which also typechecks the declaration files that ship with our dependencies. It was red only because of broken typings inside node_modules (react-markdown), never because of a file under src. The exact same errors reproduce on v0.1.x with nothing from this pull request applied, so this is pre-existing repository debt rather than a regression introduced here.

skipLibCheck keeps full typechecking of src and only skips third-party declaration files, which is what bbb-plugin-generic-link-share, bbb-plugin-h5p and bbb-plugin-session-share already do for the same reason. The bundle produced by npm run build-bundle is byte for byte identical before and after the change, so runtime behaviour is untouched.