fix: Make all toolbox blocks searchable

[mikeharv]

The basics

• I validated my changes

The details

Resolves

Fixes #10336 and #10337

Proposed Changes

Main behavior changes

• Dynamic categories are searchable. getAvailableBlocks() now looks at custom categories and gets blocks by actually calling their callbacks.
• The index rebuilds as the workspace changes. UI events, block moves and the various comment_ event types are ignored. A re-index happens only if a snapshot of the available blocks and variables has changed. Note that we can't predict how any application might need to handle manually re-indexing and no new APIs are exposed for this yet. However, manually firing another event type does cause a re-index.
• Searching for a workspace variable returns a copy of each toolbox block with a variable field set to any other workspace variable. For example, searching for 'score' will return a setter and math_change block using that variable (even if it wasn't the most recently defined variable) and exactly one getter.
• Blocks with variable field set to other variable names (hard-coded by the toolbox, defaults like item or i) that are not-yet-defined on the workspace are only matched by that name. This was a subjective product decision but seems to help prevent making the search results explode with blocks that are likely not of interest.
• Searching for a dropdown option that is not currently selected returns a variant of the source block with that option selected. If multiple dropdown options match in a single toolbox block, multiple variants of the same block can be returned.
• The flyout is refreshed only when the search category is the one showing.
• Translation strings added.
• Change listeners are removed in dispose().
• Playground has a new custom toolbox definition that makes it easier to manually test some of these cases.
• Keyboard shortcut updated to Cmd+B for Mac. This was a subjective call, but seems more consistent.
• A couple new devDependencies for tests, consistent with other plugins.

Other bugs fixed

• Field values supplied by the toolbox were being ignored. Blocks were built with newBlock(type) which effectively disregarded all fields/inputs/extra state. Now blocks are fully deserialized.
• Only the root block's fieldRow was walked (and newBlock skipped children), so values on child/shadow blocks were never indexed.
• Variable fields matched with searches for 'rename' and 'delete the' due to those respective options at the end of the list.
• Unrelated text combined into false positives. For example, a controls_flow_statements block matches 'tem', but also 'ite' (due to field value "continue with next iteration"). Because each of those trigrams make up the query "item", this block was incorrectly returned. Now we actually make sure the query is actually a substring of a piece of the block text.
• Results lagged behind by one keystroke. The old handler ran on keydown which fired before the input's value was updated, so the search matched the previous text.

Screenshots

Query	Before	After
250
alpha
alphabetic
hello-world
rename

Test Coverage

New tests were LLM-written with gentle reminders by me to follow our well-established conventions. Tests cover field and shadow values, workspace variables, flyout-only variables, dropdown variants, procedure extraState, substring checking and re-indexing.

Additional Information

This branch does not include UI updates. Those should come in a follow-up.

[gonfunko]

Why store this vs using workspace.getVariableMap()?

[mikeharv]

No good reason. Dropped it for a general workspace that is set during construction. This should take some of the guessing out about which workspace is the source of truth too.

[gonfunko]

Would be helpful if this comment noted if this should be the flyout workspace or the main/target workspace

[mikeharv]

I removed this parameter because we can now just access this.workspace directly.

[gonfunko]

Why the check for it being the root block? If there were a child block in a flyout stack that had a variable field it seems like we'd want to match/update that too?

[mikeharv]

Yeah, you're right. The problem that we only track the field name, but not where it might conceivably live within a stack. Without this guard, it might try to update the a non-existent variable field on a variable block's parent. This check allowed things to work for more common toolbox configurations, but it's definitely not fully functional in the way that it honestly should be. I'm also realizing that there isn't a similar check for non-variable dropdown fields, so I need to address that as well.

[gonfunko]

Makes sense, I think that's probably fine in practice but a comment to that effect would be helpful.

[mikeharv]

I reworked this so it now handles child blocks too. Whew.