fix: visit all connection candidates in move mode

[mikeharv]

The basics

• I validated my changes

The details

Resolves

Fixes #9631

---

Proposed Changes

• Fixes keyboard navigation skipping valid connection candidates (now matches mouse behavior)
• Replaces incremental traversal with a precomputed list of valid connection pairs
• Ensures deterministic, complete, and cyclic traversal
• Improves traversal order by reordering local connections for more natural right/down movement (configurable with a natural flag)
• Adds initialConnectionPair so traversal starts from the block’s original connection
• Refines constrained-move positioning for more consistent visual alignment

---

Reason for Changes

Keyboard navigation previously missed valid connection targets.

This PR makes traversal complete, predictable, and easier to reason about.

---

Test Coverage

• Updated tests to include previously skipped candidates (now expected).
• Manually tested keyboard navigation on complex block structures.

Documentation

Additional Information

[gonfunko]

I'd kind of prefer to just fetch this dynamically in the two places it's used; I'm not adverse to instance variables in general, but we have a lot of different connection permutations right now that make it difficult to reason about things, vs just one list of pairs.

[mikeharv]

That makes sense. My original intent with caching localConnections was to avoid recomputing them on every drag frame, since getConnectionCandidate can be hit pretty frequently during pointer moves. Happy to fetch dynamically if the readability outweighs any slight performance dips. Presumably it's worked this way for a while.

[gonfunko]

That's a good point, I think since it's just the immediate connections on the dragging block it should be fine, but worth keeping in mind if we do run into any performance issues.

[gonfunko]

I think we just always want the natural behavior

[mikeharv]

Sounds good. I wasn't sure if we might want to make it configurable or A/B testable later. For example, the natural behavior could be good for sighted users but less intuitive for screen reader users. Easy enough to add in again if we ever want it!

[gonfunko]

Makes sense! I'd ask Maribeth for her thoughts as well, but typically I prefer to shy away from configuration options without a clear and present need as anything we add to the API surface is something we're committing to maintain ~forever. Granted this method is private so that's not directly a concern here, but as a general principle that's how I tend to approach things. We also don't have any mechanism for A/B testing since we're operating solely at the library level and intentionally don't have any sort of metrics/analytics since that would affect every partner/team/product that uses Blockly and their actual end users.

[mikeharv]

Good points! Thanks for explaining.