Expose authenticated user's team membership in Blueprint/Template context

Current state

Available in policies — session.teams. Login and approval policies

already receive the signed-in user's team membership. Example from one of our

approval-policy inputs:

"session": {
  "login": "jane.doe@example.com",
  "name":  "jane.doe@example.com",
  "admin": true,
  "teams": ["developers", "admins"]
}

The same shape appears as run.creator_session.teams for the user who triggered

a run (e.g. ["developers"]). So the OIDC → Spacelift team mapping is already

piped into policy evaluation — this request is to pipe the same value into

Blueprint/Template rendering.

The artifact we want produced automatically.

Today our stacks end up with labels like:

"labels": ["Owner: john.doe@example.com", "Team: developers", "Project: ...", ...]

The Team: developers portion is the one filled from the manual dropdown.

That's the value we want auto-populated from the user's teams.

Not available in Templates and Blueprints.
Per https://docs.spacelift.io/concepts/template/configuration#available-context-properties,

the only user fields exposed are context.user.login, context.user.name, and

context.user.account. There is no team/group field.

Proposed API

Add context.user.teams — an array of strings — mirroring the

session.teams shape that login/approval policies already receive. Same source

of truth, same naming, no new mental model for users or operators.

Example Blueprint snippet (replacing the manual dropdown):

inputs:
  # (no more `team` input — derived automatically)
  - id: project
    name: Project name
    type: short_text

stack:
  name: ${ inputs.project }-${ context.random_string }
  labels:
    - "Owner: ${ context.user.login }"
    - "Team: ${ context.user.teams[0] }"     # primary team
    - "Project: ${ inputs.project }"

terraform:
  variables:
    - name: tags
      value: |
        {
          "Owner" = "${ context.user.login }"
          "Team"  = "${ context.user.teams[0] }"
        }

Open design question for Spacelift: how to handle users with multiple

mapped teams. Reasonable options: expose the full array and let Blueprint

authors choose (`teams[0]`, join(",", teams), etc.); offer a convenience

context.user.primary_team based on group ordering; or let the Blueprint

author declare a preferred team via a filter expression. We'd be happy with

the first (full array) — it composes well with existing template functions

and defers the policy decision to the Blueprint author.

Use cases

- Auto-tagging cloud resources for cost allocation / showback (primary).

- Auto-populating stack labels (`Team: …`, Owner: …) directly from

identity, instead of free-text input.

- Conditional Blueprint logic — e.g., only members of a specific team

(say, platform) can select certain backends or regions.

- Audit & compliance — the team that created a stack is provable from

the OIDC identity rather than from a value the user typed in.

Why this matters

- Cost data becomes accurate by default instead of being guarded by a manual

step that often goes wrong.

- Eliminates a class of human error (mis-selected team, blank input).

- Removes the maintenance chore of keeping Blueprint dropdowns in sync with

OIDC group changes.

- Reuses the trust boundary Spacelift already enforces (the OIDC → team

mapping that drives login/approval policies) instead of asking us to

re-establish it inside every Blueprint as a free-text input.