Tighten feature request template for parity planning traceability

[ExplodingUFO]

Problem

The feature request template captures the proposed direction, but it does not ask requesters to record the repository's execution metadata that reviewers now expect: related GitHub/Beads tracking, dependency or stacking constraints, UI/screenshot proof needs, and concrete validation lane.

That gap matters for the React Flow parity roadmap because feature requests often become stacked issues/PRs. Without those fields, maintainers have to reconstruct whether a request is independent, blocked by an earlier phase, UI-affecting, or docs-only.

Scope

Update only .github/ISSUE_TEMPLATE/feature_request.md with concise sections for:

• related GitHub issue / Beads issue, when known
• dependency, stacking, or parallelism notes
• UI/screenshot impact classification
• expected verification lane or proof marker
• out-of-scope boundaries

Do not touch product code, active React Flow parity docs, serialization docs, project status docs, or PR template files.

Acceptance Criteria

• The feature request template asks for related issue/bead traceability, dependencies/parallelism, UI/screenshot impact, validation/proof, and explicit non-goals.
• The wording stays short enough for ordinary external feature requests.
• The change is isolated to .github/ISSUE_TEMPLATE/feature_request.md.
• Whitespace/Markdown sanity checks pass.

Parallelism / Dependencies

Independent of PR #200, PR #261, PR #263, PR #265, and the whiteboard stacked PR line because it touches a separate GitHub issue template file only.