Add a bug form, and keep the next-issue skill out of the repository

[ramesh130]

Two things this repository needs before strangers arrive, neither of them
about the library itself.

next-issue joins batch-issues as a local skill. It was the only
.claude/ skill tracked, so it would have shipped with the repository while
its sibling — excluded through .git/info/exclude since it was written —
would not. Untracked here and excluded the same way, which keeps the two
consistent and keeps a personal workflow out of a public tree. Nothing about
it is secret; it is simply not something an adopter should find in a library
they cloned to read. It stays in git history at 33a5f40, which is harmless:
it is backlog-ranking instructions naming nobody and nothing private, so no
history rewrite is warranted.

A bug form that asks for the evidence this library already produces.
The useful fields here are not a generic form's. This repository ships two
artefacts built for exactly this moment — a session bundle and a
MediaSourceDoctor report — and both are redacted by construction, so a
reporter can paste either in public without leaking a signed URL or a
credential. The form asks for them by name and links what each one is.

Two fields carry most of the value. Does it also happen on a stock
ExoPlayer? is first because SuperPlayer delegates to a wrapped one, so the
answer decides whether the bug is ours at all; "not tried" is offered as an
honest option rather than forcing a guess. And which modules is the player
built with? matters more than anything else in a report, because every
optional module is a seam that is empty unless the consumer filled it — a
player without one takes a different path, so "core only" and "core plus
resilience" are two different players and the same symptom means two
different things.

Five fields are required and six are not. Each optional one has been the
difference between a fix and a guess at some point, but requiring all of them
would cost more reports than it saves.

config.yml keeps blank issues enabled: most issues here are phase specs
and exit criteria written freehand, and a form would be in the way. Its three
contact links point at the doctor, the compatibility document and the ADR
index — the three places a question is likely to be answered before it is a
bug.

Both files parse, every field is a valid issue-form type, the bug label
exists, and the links are absolute because a relative one does not resolve in
the form renderer. No library code changes.

Nothing gated this merge. Actions cannot run on this account at present (#380); local validation — both files parse, every field is a valid issue-form type, the bug label exists — is the only evidence.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HeTWwmK1KcFMrfSAre23GS