bd rename leaves stale references: close_reason, comments, the renamed issue's own text, short-form ids

[seanmartinsmith]

bd rename's reference rewrite (updateReferencesInAllIssues, cmd/bd/rename.go:103-152 at v1.3.0, unchanged on main 448c4b8) only touches title/description/design/notes/acceptance_criteria of OTHER issues, matching \b<full-id>\b:

1. close_reason is never rewritten
2. comment text is never rewritten
3. the renamed issue's own text keeps the old id: rename.go:86 sets oldIssue.ID = newID and passes the old text to UpdateIssueID, and the loop skips issue.ID == newID (:114-116)
4. short forms don't match - 12x.39, how people write sibling refs under an epic

where it bit: i used rename to repair a cross-machine child-id collision (#4796), renumbering one side's abc-12x.38..42 to .47..51. afterwards a close_reason on another bead still said abc-12x.39, which after the renumber names a different bead. nothing flags it.

#4844's bd dolt rebase has the same class: at head 1f9a0ba it renumbers through UpdateIssueIDInTx and doesn't rewrite text elsewhere (it does print the old -> new mapping).

fix shape: add close_reason (and comments, if in scope), rewrite the renamed issue's own fields, optionally match the parent-relative short form. in collision repair both sides' text meant different beads, so reporting what wasn't rewritten may beat rewriting everything

[gascityinc-sarah]

Triage: kind/bug · priority/p1 — bd rename rewrites only title/description/design/notes/AC of other issues, so close_reason, comments and the renamed issue's own text keep the old id. A close_reason can then name a different bead.
Auto-triaged by @gascityinc-sarah. Reply or relabel if this is off.