refactor(bll): introduce BLL handler for alloy cluster operations

## Summary

Alloy cluster install/uninstall (`internal/workflows/steps/step_alloy.go`) reads `config.Get().Alloy` and `config.Get().Profile` directly in workflow steps, bypassing the BLL `EffectiveValue` resolution pattern. There is no `internal/bll/alloy/` package.

## Problem

Direct `config.Get()` reads in workflow steps mean:
- No reality layer — the step cannot check what's already deployed to avoid conflicts
- No state persistence — a future alloy upgrade command would need the operator to re-specify all values
- Values are resolved at execution time deep in the workflow, making them hard to test or override

## Proposed solution

1. Create `internal/bll/alloy/` with install and uninstall handlers following the `BaseHandler[T]` pattern
2. Move config reads (`Alloy.Namespace`, `Alloy.ReleaseName`, `Profile`) into an RSL resolver with `EffectiveValue` resolution
3. Refactor `step_alloy.go` to receive resolved effective inputs rather than calling `config.Get()` directly
4. Add state persistence for alloy deployment metadata

## Design notes

Alloy is simpler than block node — fewer fields, no storage, no traffic shaping. The BLL layer will be lightweight but provides the foundation for a future alloy upgrade command.

## Scope

- [ ] Create `internal/bll/alloy/` package with handler factory
- [ ] Implement install and uninstall handlers
- [ ] Create RSL resolver for alloy effective inputs
- [ ] Refactor `step_alloy.go` to use resolved inputs
- [ ] Unit tests

Start with internal/workflows/steps/step_alloy.go and inspect existing internal/bll/ handlers that use the BaseHandler[T] pattern. Trace how Alloy.Namespace, Alloy.ReleaseName, and Profile are currently read, then compare the related resolver and state-persistence patterns. Done means the alloy package, handlers, resolver, refactored workflow step, and unit tests cover the listed scope.

Written by the indexing model from the issue text.