Fix navigation calculations and focus handling

[uvera]

I encountered with multi monitor setup.

If I have my laptop display and external display like this

focusing to left direction did not work.
This PR also handles the case where monitors are next to each other, where left direction focusing also didn't work.

I used this JS script to test overlap logic

function checkYOverlap(monitorA, monitorB) {
    return (
        monitorA.y < monitorB.y + monitorB.height &&
        monitorA.y + monitorA.height > monitorB.y
    );
}

// Test cases
const testCases = [
    {
        name: "Partial Overlap",
        monitorA: { y: 100, height: 100 },
        monitorB: { y: 150, height: 150 },
        expected: true,
    },
    {
        name: "Complete Overlap",
        monitorA: { y: 120, height: 200 },
        monitorB: { y: 100, height: 300 },
        expected: true,
    },
    {
        name: "No Overlap (Above)",
        monitorA: { y: 50, height: 50 },
        monitorB: { y: 150, height: 100 },
        expected: false,
    },
    {
        name: "No Overlap (Below)",
        monitorA: { y: 300, height: 100 },
        monitorB: { y: 150, height: 100 },
        expected: false,
    },
    {
        name: "Edge Touch (No Overlap)",
        monitorA: { y: 100, height: 100 },
        monitorB: { y: 200, height: 100 },
        expected: false,
    },
    {
        name: "Edge Overlapping (Just Touching)",
        monitorA: { y: 100, height: 101 },
        monitorB: { y: 200, height: 100 },
        expected: true,
    },
    {
        name: "Smaller bigger 1",
        monitorA: { y: 100, height: 100 },
        monitorB: { y: 80, height: 150 },
        expected: true,
    },
    {
        name: "Smaller bigger 2",
        monitorA: { y: 80, height: 150 },
        monitorB: { y: 100, height: 100 },
        expected: true,
    }
];

// Run tests
for (const testCase of testCases) {
    const result = checkYOverlap(testCase.monitorA, testCase.monitorB);
    console.log(
        `${testCase.name}: ${result} (Expected: ${testCase.expected})`,
        result === testCase.expected ? "✅" : "❌"
    );
}

[uvera]

This behaviour makes the most sense to me, we should go to previous or next workspace (depending on direction). Those actions also fall back to SwitchOutput if corresponding functions return InvalidWorkspaceIndex

[uvera]

This is here as workspace is of type usize where 0usize.saturating_sub(1) results in 0 which isn't an invalid index. This is here to allow PreviousWorkspace action to fallback to SwitchOutput on error.

[uvera]

Flipping the logic around helped avoid the issue where SwitchOutput to left resulted in output switch where it shouldn't as my external monitor is above my laptop regarding display.

[Drakulix]

Thanks for looking into this.

I'll take a closer look at the code once working on #1005 (very soon), which also revises shortcuts around output and workspace switching.

Given that will likely conflict a bit, I'll most likely cherry-pick parts of this PR.