Stand up behave.hs, a Gherkin runner for Haskell

## Summary

A BDD test runner that reads `.feature` files and binds Gherkin steps to Haskell functions — Python's `behave`, without the Python.

## Motivation

Haskell's test story is strong at the property and unit ends (`hspec`, `QuickCheck`, `tasty`) and absent at the acceptance end. A Haskell project that wants an executable specification a non-programmer can read has nothing current to reach for — the existing Cucumber ports are unmaintained or never landed. The step-definition-by-pattern model is the part worth borrowing; everything downstream of the parser can be Haskell-native.

## Scope

- Create the repo via the `scaffold-repo` flow.
- Suggested module inputs — `description`: "Run Gherkin .feature files against Haskell step definitions, under cabal test."; `topics`: `["haskell", "bdd", "gherkin", "cucumber", "testing"]`.
- Gherkin parser: Feature, Background, Scenario, Scenario Outline with Examples, Given/When/Then/And/But, tags, doc strings, data tables.
- Step registration binding a pattern to a handler, with captured arguments arriving typed rather than as `Text`.
- A context value threaded through the steps of a scenario.
- Hooks before and after feature, scenario, and step, scopeable by tag.
- Runner reporting pass / fail / undefined / skipped, printing a copy-pasteable stub for every undefined step.
- `hspec` or `tasty` integration so features run under `cabal test` alongside the existing suite.

## Open questions

1. **Step-argument typing.** Regex captures plus a `Parsable` class (behave and Cucumber's model), or a typed pattern DSL where an arity or type mismatch is a compile error? The second is the reason to do this in Haskell at all.
2. **Grammar fidelity.** Target the official Gherkin grammar so `.feature` files port between runners, or allow a Haskell-flavoured dialect?
3. **Context threading.** Explicit argument, `StateT`, or run steps in the user's own monad?
4. **Name.** `behave.hs` reads as a port and sets the expectation of behave-compatible step definitions, which isn't the plan.

## Done when

- [ ] Repo created at `alunduil/behave.hs` and adopted into Terraform (module block + `import`)
- [ ] Follow-up filed to drop the adoption `import` after apply
- [ ] Open questions above resolved and recorded in the new repo
- [ ] First milestone issue opened in the new repo

Start with the scaffold-repo flow and the Terraform module block plus import named in the issue. Record decisions for the four open questions in the new repository, then open the first milestone issue. Done means the repository exists at alunduil/behave.hs, is adopted into Terraform, and the follow-up import-removal issue is filed.

Vom Indexierungsmodell aus dem Issue-Text verfasst.