Take first, not last, binding as primary

[PEZ]

This PR fixes #126306

Also fixes the display bug mentioned in #126742.

When no contect match is found the last looked up binding was used. This made the wrong command shortcut keybinding sometimes display in places like the command palette when there are os specific bindings. Picking the first item fixes this.

I don't know, however, why the wrong bindings are in the list to begin with, so this might be just fixing the symptoms of something else that is wrong.

[PEZ]

I have some more clues now. It indeed seems like the current ”solution” in this PR only really patches the symptom of something else going wrong.

Here's is the code where this PR

	public lookupPrimaryKeybinding(commandId: string, context?: IContextKeyService): ResolvedKeybindingItem | null {
		let items = this._lookupMap.get(commandId);
		if (typeof items === 'undefined' || items.length === 0) {
			return null;
		}

		const itemMatchingContext = context &&
			Array.from(items).reverse().find(item => context.contextMatchesRules(item.when));
		return itemMatchingContext ?? items[items.length - 1];
	}

When the bug happens context.contextMatchesRules() fails to match any of te bindings that are returned from this._lookupMap.get(). Which leads to a ”best guess” fallback, which does not have enough information for making an informed guess. I saw somewhere that it should go in specificity order. And when both alternatives available for the fallback are equally specific, or bets are off.

Here are the two bindings defined for the case mentioned in #126306:

            {
                "command": "paredit.forwardSexp",
                "mac": "alt+right",
                "win": "ctrl+right",
                "linux": "ctrl+right",
                "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/ && config.calva.paredit.hijackVSCodeDefaults && !calva:cursorInComment || calva:cursorAfterComment"
            },
            {
                "command": "paredit.forwardSexp",
                "mac": "ctrl+right",
                "win": "alt+right",
                "linux": "alt+right",
                "when": "calva:keybindingsEnabled && editorLangId == clojure && editorTextFocus && paredit:keyMap =~ /original|strict/ && !config.calva.paredit.hijackVSCodeDefaults && !calva:cursorInComment || calva:cursorAfterComment"
            },

They are equally specific, only differing in wether config.calva.paredit.hijackVSCodeDefaults should be true or false, giving the command palette and other call sites an arbitrary binding alternative.

However, whatever is translating the actual keyboard events successfully interprets the context and the when clauses of the alternatives. So we shouldn't have to be guessing at all here.

[PEZ]

I notice that editorTextFocus is false in some cases where I expect it to be true. Could it be that when the command palette is rendered, editorTextFocus is no longer true, causing both when clauses to fail, and then we are down to guessing?

[PEZ]

Closing this for now, as it is quite a bit more involved than what I first thought it might be. I've summarized my findings so far in #126306.