Migrate registerTool to presentation.label for SDK 0.4.16+

[ChrBoebel]

What

experimental_statusLabels was folded into presentation (labels) in SDK 0.4.16. This swaps the option over.

Why this blocks loading rather than just dropping a label

bb validates registerTool options in the host, not in the SDK bundled into dist/, so the published artifact is rejected at load time on a current bb regardless of which SDK it was built against. Installing this repo's main (bd4b6ae) from git: on bb 0.41.0, from ~/.bb/logs/server.1.log:

18:19:18.010Z  install of bd4b6ae recorded
18:19:18.476Z  plugin advisor failed to load: registerTool: "experimental_statusLabels"
               was folded into "presentation" (labels) in SDK 0.4.16 (tool "advisor_review")
18:19:21.736Z  plugin advisor failed to load: <same>
18:20:36.584Z  plugin advisor failed to load: <same>
18:20:40.988Z  plugin advisor failed to load: <same>

466 ms after the install completed, then three more attempts. I can't say how many installs sit on 0.41 — only that on 0.41 the published artifact does not load.

Why the option is spread from a constant instead of inlined

types/ vendors the 0.4.2 declarations, which don't describe presentation, so an inline literal trips TypeScript's excess-property check. Spreading it keeps the typecheck green against both declaration generations. Verified both ways:

toolchain	declarations know presentation?	npm run typecheck	bb plugin build
bb 0.36.0 (this repo's bb-app devDependency, what CI resolves)	no	passes	passes
bb 0.41.0	yes	passes	passes

The cleaner follow-up is bb plugin migrate, which moves the plugin off vendored types/ onto the @get-bb/plugin-sdk package. Happy to do that as a separate PR — it does surface some unrelated drift (supportedPermissionModes → permissionModes, and a provider.capabilities field in the agent-configuration fixtures), which is why I kept it out of this one.

On engines

Left at bb: ">=0.35", bbPluginSdk: "^0.4.1".

I checked whether the swap mirrors today's breakage onto older runtimes, and it does not. The SDK 0.4.2 validator is a chain of hand-written per-field checks with no unknown-key rejection: registering a tool with presentation, and separately with an arbitrary made-up key, both succeed without throwing. The ≥ 0.4.16 error is a targeted deprecation guard for the removed name — it names the old key, the new key and the version, which a generic strict-object check could not produce — so there is no symmetric rejection in the other direction.

Below 0.4.16 the tool therefore registers normally and simply renders no status label. Caveat: I exercised the SDK 0.4.2 test harness and bb 0.36.0's builder, not a live bb 0.35–0.40 host. If you'd rather advertise only runtimes that render the label, bump bbPluginSdk to ^0.4.16 — that call is yours, and I didn't want to narrow the supported range silently.

Verification

npm run typecheck clean · npm test 83/83 · npm run build succeeds.

dist/ is left untouched: verify and prepack rebuild it, and I didn't want to guess which bb version you cut releases with. Say so if you'd rather have it in the diff.

[ChrBoebel]

Closing in favour of #3, which fixes the same registration failure more thoroughly — it extends the vendored declarations instead of spreading the option past the excess-property check, and adds a regression test. It also predates this PR; I had not seen it when I opened mine.

I've left the verification I did in a comment on #3, including a reproduction on bb 0.41.0 and a note on the engines floor.

#5 still needs some form of this fix in order to load, so it carries a minimal version of it for now. I'll rebase it onto #3 once that lands.