Multi-tenant / multi-subscription / multi-identity resolution is under-specified across azure-* skills

## Summary
Real developers commonly have access to far more tenants/subscriptions/identities
than the current azure-* skills account for. Example (generalized from an actual
setup, common enough to be the norm rather than the exception):

| Tenant | Subscription | Purpose | Signed-in identity |
|---|---|---|---|
| Tenant 1 | Sub 1 | Org production | business.com |
| Tenant 1 | Sub 2 | Org dev | business.com |
| Tenant 2 | Sub 1 | MSDN / Visual Studio Enterprise | business.com |
| Tenant 3 | Sub 1 | MVP / Visual Studio Enterprise | outlook.com |
| Tenant 4 | Sub 1 | PoC Dev/Test org | business.com |
| Tenant 5 | Sub 1 | Personal | hotmail.com |

That's 6 tenants across 3 separate identity/email domains, all visible to
GitHub Copilot in VS Code (multiple signed-in accounts), but **not** all
simultaneously visible to whatever single `az`/`azd` CLI session is currently
authenticated in the terminal the agent drives.

## Gaps identified

1. **No identity/tenant resolution step precedes subscription resolution.**
Skills such as `azure-cost`, `azure-quotas`, `azure-resource-lookup`,
`azure-rbac`, and `microsoft-foundry` all assume `az account list` /
`azd env get-values` is an exhaustive view of what the user can reach. It
only reflects the tenant(s) of whichever single identity is currently
logged into the CLI.

2. **VS Code/Copilot account context is conflated with CLI auth context.**
A user having multiple accounts signed into Copilot/VS Code does not mean
`az`/`azd` in the terminal is authenticated against all of them. No skill
currently documents this distinction, risking false assumptions about
what's reachable.

3. **Cross-identity tenants are invisible without explicit re-auth.**
A tenant reachable only via an `outlook.com` or `hotmail.com` login is
completely absent from `az account list` while logged in as
`business.com`. No skill instructs the agent to ask "do you have other
accounts/tenants this listing might be missing?" before presenting
subscription/tenant results as complete.

4. **No guardrail for production-named subscriptions.** Nothing
pattern-matches subscription display names (`prod`, `production`,
`org production`, etc.) to require explicit, elevated confirmation before
deploy/cost/write actions target them — it's treated the same as any
other subscription.

5. **No subscription "flavor" classification heuristics.** MSDN/Visual
Studio Enterprise, MVP, PoC Dev/Test, Personal, and Org Production/Dev
subscriptions carry very different expectations (quota ceilings, cost
sensitivity, blast radius). Nothing helps skills like `azure-prepare`,
`azure-deploy`, or `microsoft-foundry` default sensibly for exploratory/
demo work (e.g., prefer Dev/Test or Personal, never Production; flag
MSDN/MVP subs for likely quota restrictions).

6. **No session-scoped "active identity/tenant/subscription" convention.**
Once resolved for a task, nothing persists that triple across skill
invocations in the same conversation — every skill (foundry, cost, rbac,
deploy) re-derives or silently assumes it independently.

## Suggested improvements

- Add a shared **Identity & Tenant Resolution** pre-check (a common
reference doc other skills can point to, similar to `microsoft-foundry`'s
"Common Project Context Resolution") that:
- Explicitly surfaces what's currently authenticated (`az account show`)
vs. what other tenants/accounts the user has mentioned.
- Never treats one `az account list` as exhaustive; prompts the user to
switch identity (`az login --tenant ` or a fresh `az login`) if the
task might involve a tenant outside the current session.
- Add a **production-subscription guardrail**: pattern-match subscription
display names and require explicit confirmation before any deploy/write/
cost action targets a likely-production subscription, regardless of
whether it was "selected" earlier in the conversation.
- Add **subscription-flavor heuristics** (MSDN/VS Enterprise, MVP, PoC/Dev-
Test, Personal, Org Production/Dev) to help skills recommend a sensible
default target for exploratory/demo/sample work.
- Document the **VS Code/Copilot-account vs. CLI-session distinction**
directly in `azure-prepare`, `azure-deploy`, `azure-resource-lookup`, and
`microsoft-foundry`, since these are the skills most likely to run
`az`/`azd` commands under a false assumption of reachability.
- Add a lightweight **session-memory convention** for the resolved
identity/tenant/subscription triple, reused across skill calls in one
conversation, but always re-confirmed before destructive/deploy actions
if multiple candidate tenants/subs were ever mentioned.

## Suggested labels
`documentation`, `enhancement`, `multi-tenant`, `azure-mcp`, `skills`

Start by reading the existing common project context resolution in microsoft-foundry, then inspect identity and subscription handling in azure-cost, azure-quotas, azure-resource-lookup, azure-rbac, azure-prepare, and azure-deploy. Compare how these skills use az account and azd commands and how they describe VS Code/Copilot context. Done means the shared resolution, production guardrail, subscription-flavor guidance, and session convention are consistently documented across the named skills.

Written by the indexing model from the issue text.