fix: align Home/End/Page Down shortcuts with arrow-key navigation

[anishtsudo]

The basics

• I validated my changes

The details

Resolves

Fixes #10186

Proposed Changes

Update the opt-in registerNavigationShortcuts() so Home, End, Page Down, and Ctrl/Cmd+End follow the same destinations as holding arrow keys, scoped to the current block, stack, or workspace.

• Home moves to the first in-block node (usually the block itself).
• End moves to the last in-block node on the current row, not the statement end.
• Page Down moves to the last Down-reachable node in the stack and no longer enters inline value inputs.
• Ctrl/Cmd+End moves to the last focusable workspace node (last stack, then Down, then In).
• Page Up and Ctrl/Cmd+Home are unchanged.

This also stops End on a container end-statement from moving focus, and stops End on a focused container block from landing on an unreachable statement connection.

Reason for Changes

MakeCode needs these shortcuts before opting in. End previously focused the last input connection, which was wrong for C-shaped blocks.

Test Coverage

Added/updated mocha tests in shortcut_items_test.js and navigation_test.js covering both End bugs, Page Down not entering inline inputs, and Ctrl+End targeting the last focusable node.

Mocha (Chrome): Jump shortcuts + navigator helpers 26 passed; NavigationFunctions 73 passed.

Documentation

Updated the optional-shortcuts table in packages/docs/docs/guides/configure/keyboard-nav.mdx.

Additional Information

These shortcuts remain opt-in via Blockly.ShortcutItems.registerNavigationShortcuts(). They use the same In/Out/Down walks as arrow keys, so LTR/RTL follow existing navigator direction handling.

[mikeharv]

Thanks for picking this up! We will need a few changes before this can merge. None of them are a rewrite of the destination rules, which look good.

1. Navigator API:
   We try to keep new Navigator methods private or @internal unless we know an app needs to call them. These helpers are only used from shortcut_items.ts, so making them public would lock us into supporting them as API. Several of the new methods are the same while-loop with a different step and stop condition. Could they be combined to a single private method? Some shortcut logic has been moved out of shortcut_items that should probably move back. Navigator methods shouldn't need to be aware of the scoping of Home/End shortcuts.

2. Tests:
   Could you assert the actual destination node rather than getLastNodeInBlock() / getLastNodeInStack() as the expected value? Otherwise the tests will keep passing if the helper is wrong, as long as the shortcut still calls it. The older tests in this file are a good model.

3. Rebase (due to merge conflicts)
   Note that this will change some of the tests you are modifying as we've stopped using getFocusedNodeStub in favor of the real focusNode() (see #10388).

[anishtsudo]

Moved this work to a new PR with the review follow-ups: https://github.com/RaspberryPiFoundation/blockly/pull/XXXX
Closing this one to avoid a duplicate.

[anishtsudo]

Brought the review follow-ups back onto this PR instead of opening a new one.

Addressed the review:

1. Home/End/Page Down scoping is back in shortcut_items.ts. Navigator helpers are private.
2. Jump shortcut tests now use focusNode() and assert the actual destination node.
3. Merged latest main and resolved the conflicts.

Ready for another look. Thanks!

[mikeharv]

Thanks for addressing those points. I'm still not ready to merge this though. The destination rules look right, but the PR is still doing a lot of extra moving, renaming, and wrapping that the we don't need. Could you take another pass with the goal of the smallest change that implements the new shortcut destinations? Once this reads as a focused behavior change, I'll be happy to look again.