fix: recover orphan blocks when connecting to parent fails

[goughjo02]

The basics

• I validated my changes

The details

Resolves

Fixes #9266

Proposed Changes

This PR changes XML deserialization so that when a nested child block can no longer connect to its intended parent because block definitions have drifted, Blockly preserves the child block instead of leaving it uninitialized and unrendered.

When a nested XML connection fails:

• the child block is kept as a top-level block
• the child block is explicitly initialized/rendered
• the child block is disabled with the orphaned-block reason
• the child block is moved near the intended parent so the user can repair it
• the recovered block id is included in the ids returned from domToWorkspace

This also adds regression tests for headless and rendered workspaces.

Reason for Changes

The current XML loader can silently create a block in the workspace model but fail to initialize or render it when a saved child connection becomes invalid. This can happen when applications evolve block definitions independently of previously saved XML.

Preserving the invalid child block as a visible disabled top-level block prevents user data loss and gives users a path to repair their workspace manually.

Test Coverage

Added XML deserialization tests covering:

• incompatible value-input recovery
• incompatible next-statement recovery
• preserved field values on recovered blocks
• recovered ids returned from domToWorkspace
• rendered-workspace recovery, including SVG presence and disabled styling

Validation run:

• npx eslint tests/mocha/xml_test.js
• npx eslint core/xml.ts core/constants.ts core/events/utils.ts tests/mocha/xml_test.js
• npm run build -- --debug

I also ran smoke tests against the built sources to verify that recovered blocks load as top-level, initialized, disabled blocks with preserved field values and returned ids.

Documentation

No documentation updates required.

Additional Information

This intentionally prefers recovery over failure for invalid nested XML connections so that applications using Blockly with drifting block schemas do not lose user-authored block data.

[maribethb]

Hi, thank you for this PR. While we appreciate your work on it, we don't think this is the correct approach for this issue. Throwing an error upon trying to load invalid serialized state is correct, and the XML system should be changed to do this rather than creating divergent behavior between the XML and JSON systems. There is more reasoning in this comment. Feel free to respond in the bug if you have more questions. Thanks!