StateManager#STATE_SAVING_METHOD_PARAM_NAME specifies wrong default

[BalusC]

Unsure how that's possible but already in 2.3 https://github.com/eclipse-ee4j/mojarra/blob/2.3/impl/src/main/java/javax/faces/application/StateManager.java#L56-L57 and 4.0 https://github.com/eclipse-ee4j/mojarra/blob/4.0/impl/src/main/java/jakarta/faces/application/StateManager.java#L55-L56 the StateManager#STATE_SAVING_METHOD_PARAM_NAME javadoc is wrong

     * <p>
     * If this parameter is not specified, the default value is the value of the constant
     * {@link #STATE_SAVING_METHOD_CLIENT}.
     * </p>

This is not what the spec says https://jakarta.ee/specifications/faces/4.0/jakarta-faces-4.0#a6088

jakarta.faces.STATE_SAVING_METHOD —The location where state information is saved. Valid values are “server” (typically saved in HttpSession) and “client (typically saved as a hidden field in the subsequent form submit). If not specified, the default value “server” must be used. When examining the parameter value, the runtime must ignore case.

This was also the correct behavior in Mojarra 2.3, 4.0 and 4.1, however today when working on h:form prependId in Mojarra 5.0 I noticed it suddenly emitted a client state saved string in the hidden input field in a blank project. Backtracking the cause, this appeared to be the consequence of FacesConfig.ContextParam rework in #1879 whereby the javadocs of context param names were basically re-read and implemented literally without much afterthought.

Also unbelieveable this slipped through the TCK. On the other hand, it's impossible to distinguish whether the generated value of the view state hidden field represents client or server state based on the spec alone as the impls may choose their own way. It could only be validated based on observable and testable behavior of forms which are submitted against an expired HTTP session ("sever" would throw ViewExpiredException, "client" would continue to work fine) but even this is not per definition guranteed by the spec (as far as I see).