feat(graph): follow GitHub sub-issue links.

Problem

The graph only saw a sub-issue when something else connected it to its parent, like a mention in the body or a cross-reference on the timeline. A sub-issue added through GitHub's sub-issue feature with nothing else linking it was missing from the crawl, so the graph could leave an epic's children out.

Change

• The node query reads each issue's parent and its first 50 subIssues, with totalCount. A new sub-issue edge points from the child to its parent. The parent's children go in subIssues, so the crawl can reach them from either end. Each link is recorded once, on the child, including when the child's own fetch failed.
• The crawl follows a parent to its sub-issues under the usual depth, budget, hub, and cross-repo rules. The hub guard counts sub-issues and references together, and the "Hubs not expanded" list shows the same count.
• A sub-issue edge is hierarchy only. It never counts as a closing link, a solution, a competing or superseded fix, or an inbound reference for Heat.
• When a parent has more than 50 sub-issues, the node gets subIssueTotal, and the report adds a "sub-issues: read N of M (per-node limit)" line.
• The report labels the link "sub-issue of". The dashboard shows "sub-issue of" on the child and "parent of" on the parent. The graph docs and the core skill describe the edge, the 50 sub-issue limit, and the hub counting.

Testing

issue-graph graph cli/cli#14563 --depth 2 on a real epic. The seed's sub-issue cli/cli#14529 now shows sub-issue of → cli/cli#14563, and #14529's six [Design] sub-issues each show sub-issue of → cli/cli#14529.

Main reaches the same 34 nodes on that run, because those issues also link to each other through mentions and cross-references. The new edges reach extra issues when the sub-issue relationship is the only link between them.