refactor(bll): consolidate teleport step-layer config.Get() reads into BLL resolution

## Summary

Teleport operations have a split personality: the BLL layer (`internal/bll/teleport/`) resolves some fields (Token, ProxyAddr, Version, ValuesFile, Namespace, ReleaseName) through `EffectiveValue`, but the workflow steps (`internal/workflows/steps/step_teleport.go`) also read `config.Get().Teleport` directly for supplementary values.

## Problem

This split means some teleport config values go through the 7-layer resolution (and can be overridden by CLI flags, reality, or state) while others are read directly from the config file with no override path. This inconsistency makes the teleport value resolution harder to reason about and test.

## Proposed solution

1. Audit all `config.Get().Teleport` reads in `step_teleport.go` and identify which fields should participate in effective value resolution
2. Add those fields to the teleport RSL resolver and the BLL helpers (`resolveTeleportNodeEffectiveInputs` / `resolveTeleportClusterEffectiveInputs`)
3. Pass the resolved values through the workflow context or step inputs rather than reading config directly
4. Keep reads that are genuinely static config (e.g. auth mode selection) as-is — not everything needs 7-layer resolution

## Scope

- [ ] Audit `config.Get().Teleport` reads in step layer
- [ ] Move appropriate fields into BLL resolution
- [ ] Refactor step to receive resolved inputs
- [ ] Unit tests for newly resolved fields

Start by auditing config.Get().Teleport reads in internal/workflows/steps/step_teleport.go, then compare them with EffectiveValue handling in internal/bll/teleport/. Trace resolveTeleportNodeEffectiveInputs, resolveTeleportClusterEffectiveInputs, and the teleport RSL resolver to decide which fields need effective resolution. Done means appropriate resolved inputs reach the workflow without direct config reads, static reads remain, and unit tests cover newly resolved fields.

Written by the indexing model from the issue text.