Dynamic Registration of Code Actions Ignores Server Payload

Just ran into this as part of a rewrite of our Eclipse lsp4e-based plugin so that it more closely mirrors our VSCode offering. We switched over to using dynamic registration in our language server and I've just hit an awkward side effect:

we support code actions + (newly) dynamic registration

We don't support codeAction/resolve as we don't need it. This wasn't a problem with static registration, as we didn't populate CodeActionOptions.resolveProvider. However with dynamic registration, the detailed payload is ignored and LanguageServerWrapper just sets true (the left side of the boolean | CodeActionOptions union in the server capabilities).
https://github.com/eclipse-lsp4e/lsp4e/blob/06a95f28d3c117387c625d4404cacd40b37e2912/org.eclipse.lsp4e/src/org/eclipse/lsp4e/LanguageServerWrapper.java#L1221

Then when CodeActionMarker.run executes, if the action doesn't have an edit, it calls CodeActionCompletionProposal.isCodeActionResolveSupported() -

https://github.com/eclipse-lsp4e/lsp4e/blob/06a95f28d3c117387c625d4404cacd40b37e2912/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/codeactions/CodeActionCompletionProposal.java#L49

Because this only has the blanket true that the dynamic registration logic has stored, this also evaluates to true, so it then tries to call the unsupported codeAction/resolve method on our language server, which falls over...

Any thoughts on this? Looking at the rest of the dynamic registration code, is there any reason not to just unserialise the payload and store it in the server capabilities? The existing code seems to be a mixture - for some capabilities we unserialise the full payload and use it in its entirety, and for others we just register a yes/no capability. I'm assuming that this is mostly because there wasn't any demand for fuller support and so it just never needed to be implemented, rather than any technical limitation (e.g. problems unserialising)? If so, I could presumably submit a small patch that enhances what's there currently with an appropriate test?

Thanks

Start in org.eclipse.lsp4e/src/org/eclipse/lsp4e/LanguageServerWrapper.java at the dynamic registration logic around line 1221, then follow how CodeActionMarker.run consults CodeActionCompletionProposal.java around line 49. Add an appropriate test showing that the registered payload is respected and unsupported codeAction/resolve is not invoked.