chore: add GitHub issue templates

[peb-peb]

Summary

The repo has no issue templates, so incoming issues arrive unstructured. Add GitHub issue templates under .github/ISSUE_TEMPLATE/ to standardise bug reports and feature requests.

Tasks

• .github/ISSUE_TEMPLATE/bug_report.md (or .yml form) — steps to reproduce, expected vs actual, environment (browser/OS), screenshots.
• .github/ISSUE_TEMPLATE/feature_request.md (or .yml form) — problem, proposed solution, alternatives.
• .github/ISSUE_TEMPLATE/config.yml — set blank_issues_enabled and optionally a contact link.
• Apply sensible default labels (e.g. bug, enhancement) via template front-matter.

Acceptance criteria

• "New issue" shows a template chooser with Bug report and Feature request options.

Notes

• Prefer the newer YAML issue forms (.yml) for structured, required fields — but Markdown templates are fine as a first pass.

[DwayneSamuels]

For the bug form, I’d make the browser fields required only when the affected area is UI/browser-facing. Otherwise API/config bugs tend to get noisy.

A compact YAML form shape that usually works well:

• affected area: UI / API / docs / config / other
• current behavior
• expected behavior
• steps to reproduce, with a required “minimum reproducible path” textarea
• environment, conditionally framed as: OS, browser + version, deployment/runtime, package version/commit
• evidence: screenshot/video/logs
• first failure signal: the earliest visible error, console error, failed request, or wrong state

That “first failure signal” field is the one I’d add beyond the standard GitHub template. It prevents reports that only show the final broken screen.

This checklist has a practical wording for browser/UI bug reports if you want to borrow field names: https://github.com/samelogic/assets/tree/master/resources/browser-bug-test-artifact-checklist