Add a pinned, editable note field to issues

Problem Statement

There is no place on a Sentry issue to keep persistent operational context — e.g. why the issue is archived with a threshold like "ignore until it exceeds 100 events per day", root-cause notes, or "this is known noise, here's why it's safe to ignore".

To be clear, this is not a request for a comment feature — comments already exist. The request is for a persistent note that lives outside the Activity stream, because the existing options don't fit:

• Comments (Activity tab): they get buried under automatic status-change entries (regressions, escalations, resolutions). On a long-lived noisy issue, the explanation written months ago is effectively invisible to the next person who opens the issue.
• External issue linking (GitHub/Jira): far too heavyweight for a two-line operational note, and it moves the context out of Sentry, where the on-call person actually is.

Concrete example from our team: we have a crawler whose requests to certain upstream resources predictably fail (a documented quirk of the upstream API). The issue was archived with a per-day event threshold, and the reasoning lived in a comment. Later, a refactor changed a tag that participates in fingerprinting, so the same error started being grouped into a new issue — and all of the accumulated context (why it's harmless, what threshold to use, which code path handles it) was left behind on the old one. The new issue triggered an alert, and we had to re-investigate from scratch what was already known.

This also hurts team handovers: archive/ignore decisions outlive the people who made them, but the reasons don't.

Solution Brainstorm

A single pinned, editable, markdown-capable note field on the issue detail page (similar to a GitHub issue description, or a "pinned comment"):

• Always visible near the top of the issue (or in the sidebar), never displaced by Activity entries
• Editable with edit history, or simply last-writer-wins with an "edited by X" stamp
• Included in the issue API payload so it can be set programmatically (e.g. by tooling that archives known-noise issues)
• Bonus: surfaced in alert notifications (Slack/email), so the "why you can ignore this" travels with the alert

Even the minimal version (one editable text field per group, shown at the top) would cover the core need.

Product Area

Issues

The issue names the Issues product area but no files, tests, or entry points. Start by tracing the issue detail page and its issue API payload, then identify how persistent issue fields are stored and edited. Done means a pinned editable note remains outside Activity and is represented in the API, with the scope clarified before implementation.