Container resources (webfiles, repository binaries and static webapp files) in case of submounts can incorrectly reset the 'rendering mount' in the channel mngr

Since 10.0, binaries (webfiles, repository binaries and static webapp files) are also matched via an hst mount and sitemap (instead of skipped by hst matching like was done before by prefix/postfix exclusions).
We call webfiles, repository binaries and static webapp files in the HST all 'container resources'. Container resources are always loaded relative to the webapp and not to the mountpath: org.hippoecm.hst.core.linking.HstLink#isContainerResource says:

    /**
     * <p>
     *     When {@link #isContainerResource()} returns <code>true</code>, the resulting URL will be webapp relative and not
     *     relative to {@link Mount#getMountPath()}
     * </p>
     * <p>
     *     When {@link #isContainerResource()} returns <code>false</code>, the resulting URL <b>WILL</b> include the
     *     {@link Mount#getMountPath()} after the webapp relative part (context path).
     * </p>
     * @return <code>true</code> when the HstLink represents a container resource, like a repository binary, a web file
     * or a static css file served by the container.
     */
    boolean isContainerResource();

However, this currently results in the following (BIG) problem:
Whenever a submount is rendered in the channel manager, for example /sub-hap, then, in the HstDelegateeFilterBean we set the matched mount on the HTTP session. Then during processing (for example in page composer rest endpoint), we can take the 'currently edited mount' from the HTTP session. However, when concurrently container resources are requested (css, js, webfiles, repository binaries, etc), then always the root mount is matched for those requests, and the http session gets the root mount set as editing mount.