feat(simulate): local integration simulator over the generated workflows (act + gitea)

[joshua-temple]

Problem

Tier 1 validates orchestration in-process but never runs the actual generated YAML. Some
users want to exercise the real generated workflows locally before trusting them in CI.
cascade already has this machinery for its own e2e suite; it is not exposed to users.

Goal

Expose cascade's existing e2e harness as a user-facing integration simulator (for example
cascade simulate --integration or a cascade test-harness subcommand). The user supplies
their manifest and deploy stubs; cascade stages a repo, generates the workflows, and runs
them locally through act against a gitea instance with deploys stubbed, then reports the
outcome and resulting state.

Design notes

• Seed from the existing harness, do not rebuild it: e2e/harness/harness.go
  (StageRepoFromConfig, stub generation via generateStubWorkflow,
  normalizeCallbackStubPath), e2e/harness/act.go (act invocation,
  workflow_dispatch event synthesis), e2e/harness/gitea.go (gitea container),
  e2e/harness/runner.go and scenario.go (scenario driving), and the
  e2e/scenarios/*.yaml fixtures as the input-format reference.
• The harness currently lives in the e2e/ module as test code. Productizing it means
  extracting the reusable pieces behind a stable surface the CLI can call without pulling in
  test-only dependencies, or invoking the harness through a thin command layer. Pick the
  lower-risk extraction and note the module boundary in the PR.
• Deploys are stubbed exactly as the e2e suite stubs them (inert stub workflows), preserving
  the orchestration-not-deploys boundary.
• Docker is required (testcontainers + gitea + act). The command must detect a missing
  Docker daemon and fail with a clear, actionable message rather than a stack trace.

Tests

• An e2e scenario (the repo requires generator/integration features to ship an e2e/
  scenario, not just a unit test) that drives the productized path end to end against a
  staged repo and asserts the resulting state, reusing the existing harness primitives.
• A unit test for the missing-Docker detection and error message.

Acceptance

• A user with Docker can point the integration simulator at their manifest and deploy stubs
  and watch the generated workflows run locally to a reported outcome and final state.
• Without Docker, the command fails fast with a clear message.

Dependencies

#311 (shares the simulate command surface). Lower priority; heavier.