Doodlebug Fast follow tickets

[arugupta1992]

MWPW-195943
MWPW-194444
MWPW-193717
MWPW-189974

Fix Explanantion for MWPW-189974
progressBarHandler used recursive setTimeout chains with no cleanup. After cancel, timers kept running and could overwrite the bar on a second upload or after updateProgressBar(100).

Fix (in transition-screen.js)

• clearProgressBarHandler() — clears the pending timeout and bumps a generation counter so stale callbacks no-op.
• progressBarHandler — on initialize=true, clears before reset; each callback checks its captured generation before updating.
• splashVisibilityController(false) — clears on hide/cancel (upload cancel path already uses this).
• updateProgressBar(..., 100) — clears auto-progress when completion is set explicitly (covers continueInApp in upload, acrobat, etc.).

Test URLs:

• Before: https://main--da-cc--adobecom.aem.live/products/firefly/features/sticker-generator?unitylibs=stage
• After: https://main--da-cc--adobecom.aem.live/products/firefly/features/sticker-generator?unitylibs=fastfollows#

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run all PSI checks
• Re-run failed PSI checks
• Re-sync branch

Commits

• cdd072b ✅ (latest)

[Ruchika4]

Hi @arugupta1992 , since the PR has changes in common file transition-screen.js which is used for transition screen across all workflows, I am adding label platform so that a quick sanity can be done across all workflows. cc @sigadamvenkata @asonnalagi

[Ruchika4]

Nit: consider using !== null here. != null works correctly in this case but strict equality is more explicit and avoids any potential eqeqeq lint rule failures.

Suggested change

	if (this.progressBarTimeoutId != null) {
	if (this.progressBarTimeoutId !== null) {

[Ruchika4]

Nit: the if (v === 100) return inside the setTimeout callback appears to be dead code post this update. if v were 100, updateProgressBar would have already called clearProgressBarHandler(), causing the generation check above it to exit first. Please check once and see if above understanding is correct and if we need to remove it.