upgrade : correct channel resolution for partial upgrade resumption

[PalVala]

Description

Three related issues caused the interactive mas upgrade command to fail or behave incorrectly when re-run after a partial upgrade.

Bug 1 — Fatal error when Core already at latest

• upgrade_path in cli.py had no 9.2.x entry. When Core was already on 9.2.x and the user ran mas upgrade without --next-channel, the CLI fatally errored:
• No upgrade available, is already on the latest release 9.2.x

Bug 2 — Wrong target channel derived from Core alone

• When no --next-channel is provided, the CLI derived nextChannel using only Core's subscription channel. If Core had advanced to 9.1.x but an app such as Optimizer was still on 9.0.x, the CLI would target 9.2.x, skipping the required 9.0.x → 9.1.x hop. Ansible would then reject the run with:
• Unable to upgrade to 9.2.x because ibm-mas-optimizer is subscribed to a channel
• that is not compatible with this release (9.0.x).
• Supported channels are: ['9.1.x', '9.2.x-feature', '9.2.x']

Bug 3 — effectiveCurrentChannel not passed to Ansible

• Even after Bug 2 was fixed to compute effectiveCurrentChannel (oldest channel across all components), the pipeline launch code discarded it. When args.next_channel == "", masChannelParam was unconditionally set to "", causing Ansible to fall back to Core-only detection and reproduce the same wrong-target problem.

Changes

• cli.py — Added "9.2.x": "9.2.x" to upgrade_path so the CLI does not fatal-error when Core is already on the latest channel.
• upgrade/app.py — Moved getAppsSubscriptionChannel earlier so it is fetched once and reused by both channel resolution and compatibility validation, eliminating a duplicate API call. In the auto-detect path, nextChannel is now derived from the oldest channel across Core and all installed apps (effectiveCurrentChannel) instead of Core alone. Promoted effectiveCurrentChannel to self.effectiveCurrentChannel so it is accessible at pipeline launch, and passed it as masChannelParam to Ansible instead of "".

Test Results

• Verified using interactive mas upgrade on a cluster where Core was on 9.1.x and Optimizer was on 9.0.x:
• CLI correctly computed effectiveCurrentChannel = 9.0.x
• masChannelParam = 9.0.x passed to Ansible
• Ansible targeted 9.1.x, skipped Core, upgraded Optimizer successfully
• Re-run after success naturally advanced to the 9.1.x → 9.2.x upgrade