feat: Allow variable fields on shadow blocks

[B-head]

Summary

Allows field_variable on shadow blocks. Specifically, this PR permits variable_get to be placed as a shadow block, and adjusts the connection / serialization / variable cascade paths so that variable fields on shadow blocks stay in sync with the workspace's variable map.

Motivation

In a personal project, I'm defining blocks that operate on objects and that perform higher-order list operations (map / filter / reduce style blocks). Having to specify a variable explicitly every time I use one of these blocks is cumbersome. I'd like to provide blocks that come with a default variable reference preset, so users can just drop them in. Today I work around this by inserting a non-shadow variable getter, but it would be more natural UX-wise if the preset were a shadow that the user could simply replace with another variable.

For context, my own use case involves combining this with @mit-app-inventor/blockly-block-lexical-variables. However, the changes in this PR work with stock Blockly's field_variable in the same way, so this is not a plugin-specific feature. That said, I have not yet verified whether this PR alone is sufficient to make the lexical-variables combination work end-to-end as intended; additional adjustments may be required.

Why a draft?

I judged that ad-hoc patching was not the right way to fix this. The code in this PR is also pure AI-generated code that I have not yet reviewed in detail myself.

The patches in this PR work around several existing issues in the codebase, which makes them fragile and likely to break under future changes. The right fix would be a more fundamental design change, but most of those changes would be breaking. Rather than push that decision unilaterally, I'd like to report the issues I uncovered while building this experimental implementation and ask for guidance on how to proceed.

For transparency: the issue analysis below was put together through a dialogue with Claude Code. I have verified the substance of the findings myself, but some of the wording is left as-is from the AI.

What this PR implements

Just allowing variable fields on shadow blocks isn't enough on its own. To make a variable field on a shadow block behave equivalently to a non-shadow variable_get, the following two consistency requirements had to be addressed:

• Cascade on variable deletion: when a variable referenced by a variable field inside a shadow block is deleted via Workspace.deleteVariable, the shadow's reference must also be cleaned up so that the workspace stays consistent.
• Undo/redo for changes inside shadow blocks: changes to a variable field on a shadow block must be properly undoable / redoable.

To make these work, the PR routes around the existing event system / serialization / connection paths in several places. The structural reasons why those workarounds were necessary are documented in the Known issues section below.

Known issues

This section is context for reviewers, not a list of fixes proposed by this PR. For each item, I'd like your judgement on whether it should be (a) folded into this PR's scope, (b) split out into a separate issue, or (c) marked WONTFIX.

1. Shadow lifecycle is not a first-class undo/redo operation

Symptom: Creating and destroying a shadow block does fire BlockCreate / BlockDelete events, but events_block_create.ts:48-50 and events_block_delete.ts:54-57 force recordUndo = false whenever isShadow() is true, so these events never end up on the undo stack. Field edits inside a shadow are similarly not recorded. In effect, the shadow lifecycle relies entirely on "side effects of the parent's events plus implicit respawning along the connect/disconnect path."

Impact on this PR: Because shadow blocks are now allowed to carry variable fields, there is no way to undo a variable-id change inside a shadow, and the cascade for variable deletion has no choice but to ride on the parent block's events.

Suggested upstream fix: Drop the forced recordUndo = false on shadow events and promote the shadow lifecycle to a first-class undoable operation. However, this is tightly coupled to the meaning of ConnectionState.shadow (see section 2 below), so it can't really be fixed in isolation. I think of it as an RFC-level item for a major version (v14).

2. ConnectionState.shadow conflates template and live snapshot

Symptom: serialization/blocks.ts:322 saveConnection calls getShadowState(true), which serializes the live shadow block's current values. On load, that serialized state is written back into shadowState_ via setShadowStateInternal in connection.ts, and then re-serialized again by serializeShadow at L622/L628/L632. After even a single save/load round trip, the original template is lost and the most recently saved live state becomes the new template. As a result, "the shadow template right after dropping from the flyout" and "the shadow template after a save/load cycle" no longer mean the same thing.

Impact on this PR: During a cascade, parent.shadowState may still be a template, or it may already be a live snapshot, depending on the calling context. This forced us to introduce a Case 1 (template != live) / Case 2 (template == live) split and an isSelfTemplate flag.

Suggested upstream fix: Split the ConnectionState schema into shadowTemplate and shadowOverride. This is a serialization-output change and therefore clearly breaking. It really should be solved together with section 1.

3. Connection.disconnectInternal implicitly respawns shadow blocks

Symptom: Around connection.ts:311, when a non-shadow child is disconnected, the parent silently runs respawnShadow_(). This is a side effect that's invisible to API consumers, and it triggers a chain like disconnect → respawn → getOrCreateVariablePackage → recreates a variable that was about to be deleted.

Workaround in this PR: Introduced a Workspace.suppressShadowRespawn flag and wrapped the entire cascade dispose loop with it to suppress respawning.

Suggested upstream fix: Add a {respawnShadow?: boolean} option to disconnect() so the side effect becomes opt-in at the call site. Changing the default would be feat!:; rewriting only internal callers while keeping the surface API compatible could potentially go in as a non-breaking feat:. If section 1 is being addressed, the cleanest path is to replace the implicit respawn with an event-driven mechanism instead.

4. getOrCreateVariablePackage's lookup-or-create semantics

Symptom: variables.ts:691-702 returns an existing variable or creates one if missing. This is convenient when loading variables, but in order-sensitive contexts like a cascade, the result depends on whether you call it before or after the deletion has happened. In this PR, we had to split the cascade into two passes to make this work.

Suggested upstream fix: Add an explicit "always create" API such as createVariableSameId(workspace, id, name, type). Since this leaves the existing getOrCreateVariablePackage untouched, it's an additive change and could land as a feat: in v13. The conditions are that it should still fire a VarCreate event like the existing createVariable, and that its behavior when a variable with the same id already exists should be explicitly defined (throwing seems safest).

5. getVariableUsesById returns the same block multiple times

Symptom: variables.ts:852-867 returns the same block multiple times if a single block contains multiple fields referencing the same variable. This PR works around it with a local Set<string> dedupe inside deleteVariable, but Blockly.Variables.deleteVariable at variables.ts:879 uses uses.length directly as the count shown in the DELETE_VARIABLE_CONFIRMATION dialog. That makes it a user-visible bug that double-counts the same block. The uses.length > 1 threshold check is also off, so there are cases where a confirmation dialog appears even though only a single block uses the variable.

Suggested upstream fix: Make getVariableUsesById itself dedupe by block id. The internal callers (VariableMap.deleteVariable at variable_map.ts:308 is already defended by an isDeadOrDying() guard; the deprecated wrappers just forward) are unaffected, and the dialog bug above gets fixed as a bonus. This should be doable as a fix: in v13. Since it's independent of this PR, it could also be split out as a separate PR.