MWPW-191633: Enable milolibs/unitylibs query params on CC stage URLs

[nkthakur48]

• Enable milolibs/unitylibs query params on stage URLs

Resolves: MWPW-191633

Test URLs:

• Before: https://main--cc--adobecom.aem.live/?martech=off
• After: https://MWPW-191633-support-milolibs-stage--cc--adobecom.aem.live/?martech=off

Note that this has a supporting PR in adobecom/da-cc as well at adobecom/da-cc#45

Dev validation: (using browser overrides)

URL 1: https://www.stage.adobe.com/products/firefly/features/remove-person-from-photo.html?milolibs=ratko-test&unitylibs=doodlebug-v152-2
URLs by domain: ff-doodlebug_milolibs_unitylibs_js_urls.md

URL 2: https://www.stage.adobe.com/creativecloud/plans.html?milolibs=ratko-test&unitylibs=doodlebug-v152-2
URLs by domain: plans_milolibs_js_urls.md

URL 3: https://www.stage.adobe.com/products/firefly/features/remove-person-from-photo.html?milolibs=ratko-test
URLs by domain: doodlebug_milolibs_js_urls.md

URL 4: https://www.stage.adobe.com/products/firefly/features/remove-person-from-photo.html?unitylibs=doodlebug-v152-2
URLs by domain: doodlebug_unitylibs_js_urls.md

[nkthakur48]

Explanation for this change:
unitylibs/scripts/utils.js is consumed cross-origin — when a project like da-cc loads it from a custom unity branch, the file is served from https://my-branch--unity--adobecom.aem.live. In ES modules, a root-relative path like /libs resolves against the module's origin, not the page's origin. So import('/libs/utils/utils.js') was hitting https://my-branch--unity--adobecom.aem.live/libs/utils/utils.js - a 404.

This only became visible after the stage fix: on .aem./.hlx. hosts, setLibs already returns an absolute Milo URL, so module origin doesn't matter. On stage with branch === 'main', it now falls through and returns the relative prodLibs = '/libs', which exposed the bug.

Passing ${window.location.origin}/libs instead makes prodLibs an absolute URL anchored to the page's origin, so the import always resolves correctly regardless of where the module was loaded from.