docs(agents): move issue tracking to GitHub and resync AGENTS.md with the repo - #132

Findings lived in markdown reports under untracked/, which cannot be
assigned, linked to a PR, or closed by merging one. The 2026-08-06
review had accumulated three re-verification passes stamped inline
and was still wrong: 13 of its 25 findings had been fixed by commits
that landed after the last pass, including the one that pass called
the largest open item.

Records the workflow instead — search before filing, re-verify
against the tree with dated evidence, label taxonomy, closing
keywords, relationships over restated context.

Upstream work moves from untracked/upstream/ drafts to issues with
the upstream label. The prohibition on writing to external repos is
widened from "file issues" to every write GitHub offers, and made
explicit that approval is neither durable nor implied. The issue is
a drafting workspace and a context anchor for dependents, not a
permanent mirror: once filed upstream it is closed unless something
here is still being iterated on.

Assisted-by: Claude:claude-opus-5

Adopts the kernel's Assisted-by: convention
(https://docs.kernel.org/process/coding-assistants.html) plus an
ai-assisted label, so a reader can tell at a glance which findings
came from an agent and which model produced them.

Three details the format invites getting wrong, spelled out because
both were live here: the brackets in
AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] mark optionality and are
not typed; tools are named analysis utilities that produced evidence
in the body, so an ad-hoc repro script does not qualify and most
issues carry none; and a bracketed context-window suffix has to come
off the model id, since claude-opus-5[1m] would read as the tool
syntax.

Also carries over the two rules that make the convention mean
something. Agents must not add Signed-off-by anywhere — only a human
can certify the DCO. And an agent-filed issue must say what it could
not do: whether the repro was run, whether a fix was built or
tested, what is still unverified. A report that reads as verified
but is not costs a maintainer more than no report.

Applied retroactively to #120-#131.

Assisted-by: Claude:claude-opus-5

Backfills the requirement this branch introduced. The limitations
page documented friction that had no issue behind it, so the page
stated a rule its own entries did not satisfy.

Eight issues now cover the seven limitation sections plus the one
private-API use with no section of its own (no public export for
ModelMetaclass). Granularity follows the friction, not the table
rows: QueryInstance._hash belongs to the id-condition limitation
that forces it, and Table._update_table to the update_many() gap, so
neither private-API row gets an issue of its own.

The issues are deliberately thin. They link to the docs section
rather than restating it, because the page is the artifact that
ships — versioned with mike, checked by strict mode, and written to
be read standalone by an upstream maintainer, which makes it the
ready-to-send proposal already. An issue body cannot be any of
those, and nothing reviews it when the code it describes moves. What
the issues carry instead is the part a page cannot: status,
priority, relationships, and the decision about whether anything
reaches upstream.

Assisted-by: Claude:claude-opus-5

An at-mention in an issue, comment, PR body, or commit message sends
a real notification, and quoting does not suppress it: a draft
inside a block quote still pulls the person in, and so does one
under a heading that says "do not post". Draft collateral that sat
inert in a git-ignored file for weeks became live the moment it was
pasted into an issue, and notified an upstream maintainer about a
reply nobody had approved sending.

That is the same harm the upstream rules exist to prevent, reached
by a route those rules did not cover — they governed writing to
other repositories, not writing about other people in this one.

The mitigation is to write the name without the at sign, or wrap
the token in a code span, since GitHub does not create mentions
inside code.

Also records the milder neighbour, verified rather than assumed:
referencing an upstream issue posts a visible cross-reference on
their tracker. That is worth it for a genuine tracking link and this
repo has always done it, so the guidance is to keep such references
where they belong rather than to avoid them.

And tightens the closing-keyword rule. A keyword fires on merge and
will close an issue that someone has deliberately reopened, so it
belongs only on issues the merge genuinely resolves.

Assisted-by: Claude:claude-opus-5