chore(github): add the bug-report issue form proposed in #1847 (five fields, negative control required)

[xmasyx]

Adds the bug-report issue form proposed in #1847, unchanged from the text posted there on Aug 18. Opening it as a PR now because the thread has kept asking process questions the template answers — most recently @Drizzt321 asking whether a PR should be accompanied by an issue.

Context: @garthsch asked whether feedback needed a standard format; @danielmiessler answered that the recent wave is the format — version + file:line + a repro against a clean tree + a suggested fix — and said it would be encoded as an issue template.

Five fields. The four above, plus one the last batch showed makes a report cheap to accept: the negative control, i.e. how the reporter proved the check would have gone red. It states the defect without reference to any fix, so a maintainer reproduces a bug instead of reviewing a patch. That is also the cheapest filter against generated-code submissions.

Three pre-submit boxes. Searched prior issues; repro runs on a clean tree, not a modified install; personal data removed from pasted output. The third exists because DA-written reports tend to arrive carrying the reporter's home path and real name.

config.yml keeps blank issues enabled and points questions, ideas and "should I upgrade?" at Discussions.

Deliberately left out: a feature-request form, and any label or triage policy — those are maintainer calls, not mine.

Both files parse (js-yaml). Required fields: version, summary, location, repro, negative-control; suggested fix optional.

Happy to have this closed if the shape isn't right, or reworked in whatever direction you prefer.

[Drizzt321]

@xmasyx also probably update the Contributing section on the main README, to give preferred path for bug vs other feature PR submissions vs just creating an issue, please. It'd help me a lot to have a clear protocol/desired method.

[xmasyx]

Good call, and you're right that it's missing. I checked before answering: the Contributing section is four generic steps (fork, change, test, submit) with no routing between a bug, a feature, and simply filing an issue, and there is no CONTRIBUTING.md in the repo at all.

The config.yml in this PR covers half of what you're asking for — questions, ideas and "should I upgrade?" go to Discussions, defects go to issues — but nothing there tells you when a fix should arrive as a PR versus as a report.

I left the README out of this PR deliberately. The public repo is generated from a private source tree, so the README wording is @danielmiessler's call rather than mine, and a docs edit riding along with the template would blur what he's approving. Happy to open a separate PR with a short routing block under Contributing if he wants one: defect you can reproduce → bug form; fix you have already tested → PR that references the issue; question or idea → Discussions.

Thanks for pushing on this — the protocol question is the reason the form exists in the first place.