feat(hooks): run custom step types as lifecycle hooks (kind: step) @osterman (#2658)

## what

• Add a new kind: step component-lifecycle hook that delegates to the workflow/custom-command step registry, making every registered step type (container, http, toast, log, markdown, …) runnable on terraform lifecycle events — name a step type: and pass its parameters under with:.
• Plumb the operation outcome to hooks: user hooks now fire on the failure path (not just success), a new when: success|failure|always selector (default success) controls outcome-based firing, and {{ .status }}/{{ .exit_code }}/{{ .error }} template context plus ATMOS_HOOK_* env vars (alongside component/stack) let a hook announce exactly what happened.
• Tighten the hooks JSON schema into a structured per-hook envelope (kind enum incl. step, events, on_failure, when, type, with, retry) across all three schema copies, kept non-breaking (additionalProperties: true).
• Add docs (hooks reference + new sections), a PRD, a changelog blog post, and a roadmap milestone; unit tests cover routing, nested with: decode, when filtering, outcome template/env exposure, retry, and on_failure.

why

• The hook system previously hard-coded a small kind list (store, command, infracost, checkov, kics, trivy, git); every new capability meant a new kind. Reusing the existing, well-tested step registry lets the whole step library work as hooks without forking the abstraction.
• A key use case — "the VPC component in the foobar stack failed" — was impossible: after-* hooks fired only on success (cobra skips PostRunE on error) and the outcome reached only CI hooks, never user hooks. Firing user hooks on failure with when + outcome context closes that gap while defaulting to success-only so existing hooks (e.g. store) keep their behavior.

references

• PRD: docs/prd/hooks-step-types.md
• Docs: /stacks/hooks#kind-step-run-a-step-type and #reacting-to-success-or-failure
• The http step type used in the Slack example lands in a separate PR; the bridge works today with every registered step type.

Summary by CodeRabbit

• New Features
  • Added composable declarative when conditions for workflow steps, hooks, and structured custom-command steps (including predicate logic and workflow-style retry).
  • Introduced kind: step hooks to run any registered workflow/custom-command step type via type, with, retry, env, and on_failure.
  • Hook lifecycle outcomes are now exposed to hook templates and available as ATMOS_HOOK_STATUS, ATMOS_HOOK_EXIT_CODE, and ATMOS_HOOK_ERROR.
• Bug Fixes
  • Steps/hooks now correctly skip when conditions don’t match, and verification respects both outcome status and CI gating.
• Documentation
  • Updated docs/schemas/examples, and standardized Terraform lifecycle hook event names to dotted format.
• Tests
  • Added/updated coverage for conditional execution, schema validation, and the step hook engine.

Skip fork autofix and refresh setup-go pins @osterman (#2659)

## what

• Skip the atmos.ci autofix job when a pull request comes from a fork.
• Keep the existing atmos-pro[bot] loop guard and same-repo PR autofix behavior.
• Refresh eight actions/setup-go v6 SHA pins to match the current upstream v6 tag.

why

• Fork PRs do not receive OIDC, repo variables, or writable credentials, so atmos pro commit cannot authenticate or push fixes.
• Skipping the job avoids guaranteed red checks for external contributors while preserving formatting automation for internal PRs.
• The verify workflow checks that SHA-pinned actions match their tag comments; the previous setup-go pins pointed at v6.4.0 while labeled as v6.

references

• Validated with workflow YAML parsing, upstream tag checks for actions/setup-go, and commit hook check yaml.

Summary by CodeRabbit

• Chores
  • Updated multiple CI/E2E workflows to pin the Go setup action (actions/setup-go@v6) to newer immutable revisions for more consistent build and test runs.
  • Improved the automation logic to avoid running the auto-fix job on fork-originated pull requests where commit/push authentication isn’t supported.
  • Added inline documentation in the automation workflow explaining the fork/OIDC limitation.