Include more information about the .feature files status in implementation

[nullhack]

Example Output

$ beehave status
FEATURE                              STATUS          SCENARIOS  STUBS  ISSUES
guard_bee_inspects_hive              passing         12/12      0      0
worker_bee_nectar_collection         needs-examples  0/0        —      —
queen_bee_egg_laying                 needs-examples  0/0        —      —
scout_bee_dance_communication        needs-stubs     8/8        8      0
drone_bee_mating_flight              needs-impl      6/6        3      0
hive_temperature_regulation          needs-fixes     5/5        0      2
foraging_bee_pollen_baskets          needs-breakdown —          —      —

Proposed Flags

• beehave status — show all features with status
• beehave status --stage <stage> — filter by stage (e.g., --stage needs-examples)
• beehave status --short — only show feature name + status (for piping to other tools)
• --json for machine-readable output (consistent with existing beehave check behavior)

Implementation Notes

The status can be derived from data beehave already computes:

1. needs-breakdown: Raw Gherkin AST has a Feature node with description text but zero Rule children.
2. needs-examples: Raw Gherkin AST has Rule nodes but parse_feature() returns an empty scenarios dict (currently silently dropped when iterating rule.children for scenario nodes).
3. needs-stubs: parse_feature() returns Scenarios but discover_tests_dir() finds no matching test directory.
4. needs-impl: Test directory exists, tests map to scenarios, but all have is_stub == True.
5. needs-fixes: beehave check returns non-empty violations list.
6. passing: Tests exist, none are stubs, beehave check returns 0 violations.

The key change is in gherkin.py — currently Rule-only features are discarded entirely by parse_feature(). The parser needs to preserve Rule metadata even when Scenarios are absent, so the status command can distinguish needs-breakdown (no Rules) from needs-examples (has Rules, no Scenarios).

Alternative Considered

Add a --strict flag to beehave check that fails on zero-scenario features. Rejected because it conflates "not developed yet" with "broken" — teams need to see their backlog, not a false error.