What?

Fixes the bare vus shortcut precedence introduced by PR #5794 so it only clears lower-priority scenarios when the bare vus value comes from a higher-priority configuration tier.

Also keeps explicit empty stages from activating a lower-tier bare vus, while still allowing a higher-tier --vus to override lower empty stages and run as shared iterations.

Why?

After the recent bare --vus change, any final Options value with VUs.Valid and Scenarios != nil could replace scenarios during derivation, regardless of where vus came from. A config-file default like { "vus": 3 } combined with a script that defines scenarios would silently run a default shared-iterations scenario instead of the script's scenarios, causing major load profile corruption.

Root cause: DeriveScenariosFromShortcuts() only sees the consolidated options, so it could not distinguish higher-tier CLI/env/script overrides from lower-tier defaults that should not override explicit scenarios.

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass.

Validation performed:

• go test ./internal/cmd ./lib/...
• go test ./internal/cmd/... ./lib/...

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation: grafana/k6-docs#NUMBER if applicable
• I have updated or added an issue to the TypeScript definitions: grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

Follow-up to #5794 / #5793