[Bug][Core] Fix for Chordal Hold: stuck mods when mod-taps are pressed in a stuttered sequence.

[getreuer]

I discovered an input sequence where Chordal Hold (#24560) leaves a mod in a stuck state.

Description

Repro example: Suppose keys LSFT_T(KC_A) and LCTL_T(KC_B) are on the same hand, and the following input is made:

1. LSFT_T(KC_A) down
2. Wait unit the tapping term (Shift is now active)
3. LCTL_T(KC_B) down
4. LSFT_T(KC_A) up
5. LSFT_T(KC_A) down
6. LCTL_T(KC_B) up
7. LSFT_T(KC_A) up

where steps 3-5 are done quickly, within the tapping term. Then even after all keys are released, the Shift mod is stuck. The bug happens similarly with layer-tap keys or a mix of a mod-tap and a layer-tap key.

Fix: Handling goes wrong on step 5 of the example above, in the code waiting_buffer_chordal_hold_taps_until(). This function marks buffered events as tapped. The problem is that this inappropriately marks the LSFT_T(KC_A)-up event from step 4 as tapped, mismatching that the key was considered held on step 1. I realized that in this function it only makes sense to mark buffered press events as tapped. The fix amounts to adding an "if (record->event.pressed)."

To verify, I've added a "two_mod_taps_keys_stuttered_press" unit test simulating the repro example. This test fails before this PR and is fixed after.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout (addition or update)
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).