[GPTEINFRA-16720] Fix showroom multi-user mode trigger in combined CI

[prakhar1985]

Problem

In combined CI (multi-tenant loop), user2's showroom pod entered multi-user mode incorrectly, creating namespace user2-showroom-user1 instead of user2-showroom. Each user also saw duplicate portal messages from prior users' Phase 1 runs.

Root Cause

Two layers of state contamination between sequential user Phase 1 runs:

1. File state: The agnosticd.core.agnosticd_user_data lookup in the showroom role's prepare_variables.yaml reads provision-user-data.yaml. After user1's Phase 1, this file contains users.user1. When user2's showroom role runs, the lookup returns _showroom_user_data.users defined → multi-user mode → wrong namespace.

2. In-memory state: set_fact persists host-level facts across include_role calls in the same play. The combine() in prepare_variables.yaml merges onto dirty _showroom_user_data from the previous iteration even if the file is clean.

Note: user-info.yaml is only used for display messages — not the multi-user mode trigger. Previous fix attempts targeted the wrong file.

Fix

Two-part fix in provision_user.yml wrapping each user's Phase 1:

1. Strip users key from provision-user-data.yaml — preserves global keys (cluster credentials, endpoints) but removes per-user entries so _showroom_user_data.users is undefined → single-user mode
2. Reset _showroom_user_data: {} — clears dirty in-memory fact so combine() starts from a clean slate each iteration

Merge-back after Phase 1 uses combine(recursive=True) to restore all prior users plus the current user's new data.

Also retains existing user-info.yaml scoping and Phase 1 message stripping for clean portal messages.

Validation

Confirmed fixed in LB2863 combined CI test order — user2's showroom namespace is correct and portal messages are clean.

Jira: GPTEINFRA-16720