feat: issue gardener — daily backlog grooming agent

Bash pre-checks (zero tokens): duplicate titles, thin issues, stale
issues, missing deps. Then claude -p for analysis and action.

Escalates decisions in compact format:
  1. #123 "title" — reason (a) opt1 (b) opt2 (c) opt3

Cron: daily 07:00 UTC. Light touch — grooms, doesn't invent work.

gardener/best-practices.md

@@ -0,0 +1,53 @@
+# Gardener Best Practices
+
+## What the gardener does
+Keeps the issue backlog clean so the dev-agent always has well-structured work.
+Runs daily (or 2x/day). Light touch — grooming, not development.
+
+## Issue quality checklist
+A "ready" issue has:
+- [ ] Clear title (feat/fix/refactor prefix)
+- [ ] Acceptance criteria with checkboxes
+- [ ] Affected files listed
+- [ ] Dependencies section (if any)
+- [ ] No duplicate in the backlog
+
+## When to close
+- **Duplicate**: newer issue closed, comment links to older one
+- **Superseded**: explicitly replaced by another issue (link it)
+- **Stale + irrelevant**: no activity 14+ days AND no longer makes sense given current state
+- **Completed elsewhere**: work was done in another PR without referencing the issue
+
+## When to escalate (NEVER decide these)
+- Issue scope is ambiguous — could be interpreted multiple ways
+- Two issues overlap but aren't exact duplicates — need human to pick scope
+- Issue contradicts a design decision (check PRODUCT-TRUTH.md, ARCHITECTURE.md)
+- Issue is feature request vs bug — classification matters for priority
+- Closing would lose important context that isn't captured elsewhere
+
+## Escalation format
+Compact, decision-ready. Human should be able to reply "1a 2c 3b" and be done.
+
+```
+🌱 Issue Gardener — 3 items need attention
+
+1. #123 "Push3 gas optimization" — duplicate of #456 "optimizer gas limit"?
+   (a) close #123  (b) close #456  (c) keep both, different scope
+2. #789 "refactor VWAPTracker" — stale 21 days, VWAP was rewritten in #603
+   (a) close as superseded  (b) reopen with updated scope  (c) keep, still relevant
+3. #234 "landing page A/B test" — 8 acceptance criteria spanning 4 packages
+   (a) split into: UI variants, analytics, config, deployment  (b) keep as-is
+```
+
+## What NOT to do
+- Don't create new feature issues — gardener grooms, doesn't invent work
+- Don't change issue priority/labels beyond adding missing deps
+- Don't modify acceptance criteria that are already well-written
+- Don't close issues that are actively being worked on (check for open PRs)
+- Don't rate-limit yourself — max 10 API calls per run for issue reads, 5 for writes
+
+## Lessons learned
+- Review bot hallucination rate is ~15% — gardener should verify claims about code before acting
+- Dev-agent doesn't understand the product — clear acceptance criteria save 2-3 CI cycles
+- Feature issues MUST list affected e2e test files
+- Issue templates from ISSUE-TEMPLATES.md propagate via triage gate