Using "o" and "O" in jsdoc style comments fails to create comment line leaders in correct alignment or at all

Describe the bug/Steps to reproduce the behavior:
In my current VSCode setup, it seems only JSDoc-style block comments get the asterisk line leaders auto-inserted.

1. In Insert mode, using Enter, Ctrl + Enter, Ctrl + Shift + Enter (in other words, all the default VSCode behaviors) work as expected.
2. In Normal mode, hitting just "o" will add the leading asterisk and a space, which is great.
3. In Normal mode, hitting just "O" will not add the leading asterisk and the space afterwards. The cursor ends up at the same indentation level as where the asterisk would go, in Insert mode. I would then have to type the asterisk and the space manually.
4. In Normal mode, using a count and "o" will go from this:
   
   to this monstrosity ("2o" was used. As far as I know, where the cursor is placed on the line when the keybind is inputted does not matter):
   
5. In Normal mode, using a count and "O" will essentially scale up the problem in number 3. Typing the asterisk and space is the manual fix here as well, since there's already a cursor on all the lines ("2O" was used with the cursor on line2/the block terminator/"*/"):
   

Steps To Reproduce

1. Open a blank file
2. Change file type to JavaScript or JavaScript module (or probably the other variations too)
3. Start a JSDoc style comment with /**
4. Hit Enter to get the first auto-generated line leading asterisk.
5. Optionally format the terminating sequence to be in line with the other two lines (it's moved to the next line with no leading space)
6. Try out any of the above examples in the bug description section.

Expected behavior
Something like this: (I personally wouldn't mind if cursor only ended up on the upper-most line for "O" and lower-most line for "o" either)

Environment (please complete the following information):
I really hope this isn't just an issue with my setup.

• Extension (VsCodeVim) version: 1.27.1
• VSCode version: 1.85.1
• OS: Windows 11

Additional context
I did try fixing this using the various JSON remapping facilities

{
  // ...
  "vim.normalModeKeyBindingsNonRecursive": [
    {
      "before": [
        "o"
      ],
      "commands": [
        "editor.action.insertLineAfter",
      ],
      "after": [
        "i"
      ]
    },
    {
      "before": [
        "O"
      ],
      "commands": [
        "editor.action.insertLineBefore",
      ],
      "after": [
        "i"
      ]
    }
  ]
}

Somewhat frustratingly, it works perfectly "fine" (as far as I was concerned or aware of) for "O", with and without the count, but will not work past the first line with "o". I tweaked it a bunch, trying to use the recursive version of keymaps to take advantage of the working "O" behavior and whatnot, but to no avail. I believe using these keymaps also inherently drops the feature of "o/O" copying the typed line multiple times (indicated by the (lack of) multiple cursors)

Reproduce the JavaScript JSDoc cases in VS Code, focusing on Normal-mode o/O with and without counts. Trace the normal-mode insertion and comment-leader handling paths; done means o and O preserve aligned asterisk leaders and counted commands behave consistently without manual correction.