port-the-report-upstreamlisted

# Port the report upstream (but re-verify every anchor) ## Purpose A port inherits its parent's bugs. Fixing one downstream and stopping there leaves the defect live for the larger user base, and leaves the two projects diverging on a file that was identical — which is a cost the downstream maintainer will pay at the next sync. Reporting in both houses doubles the value of one investigation for near zero extra investigation. The trap is that it feels like copy-paste, and it is not. Everything *about* the code differs even when the code doesn't: line numbers, the name of the subcommand you tell people to run, which labels exist, whether commits need a sign-off, and — worst, because it looks like it worked — issue numbers, which silently autolink to whatever issue happens to have that number in the repo you're posting to. A ported report with stale anchors is worse than no report: it tells the second maintainer you didn't actually look at their code. ## When to use - The repo you found a bug in is described as a port/fork of another project, or you recognize the file structure. - You've landed (or are about to land) a downstream report and the offending file looks unmodified from its origin. - Direction is symmetric: upstream→downstream is the same job. ## When NOT to use - The two copies have genuinely diverged at the site you're reporting — then it's a new investigation in the second repo, not a port. Diff first. - The upstream project is dead/archived, or the fo