fix(review): assign the PR's linked issues, not just the PR itself

[JSONbored]

Summary

• gittensor:priority propagation (resolveIssueLabelsForPropagation, linked-issue-label-propagation-fetch.ts) requires the PR author to be the linked issue's own author OR a GitHub assignee of it -- deliberately stricter than gittensor:bug/gittensor:feature, which trust a maintainer-authored issue (trustMaintainerAuthoredIssue: true) without formal assignment, since priority is the scarce, maintainer-hand-picked reward label.
• The existing auto-assign action (feat(agent): auto-assign PR opener as GitHub assignee (config + wiring) #3182, "auto-assign PR opener") only ever assigned the PR's opening contributor to the PR itself, never to the issue(s) it closes -- these are separate GitHub objects with separate assignee lists, even though both happen to sit behind the same /issues/{number}/assignees REST endpoint.
• Since our issues are almost always opened for open pickup and rarely formally assigned (the propagation config's own comment in gittensory-repo-focus-manifest.ts says this explicitly), a contributor who picks one up and opens a PR against it could never actually satisfy the assignee check -- so gittensor:priority could never propagate to a contributor's PR in practice, even when the linked issue clearly carried the label. gittensor:bug/gittensor:feature worked fine (they don't need the assignee check at all), which is exactly the asymmetry reported.
• Extends the assign action to also best-effort assign the same login to each linked issue (capped at 10 -- ASSIGN_LINKED_ISSUES_MAX, since a PR overwhelmingly closes 1-3 issues), reusing ensurePullRequestAssignee as-is (it already hits the generic issues-assignee endpoint; only the issue number passed differs). Each issue's assignment is independent and best-effort, so one failing write never affects another issue's assignment or the PR-assign outcome. This makes the existing, already-reviewed "author or assignee" ownership check actually satisfiable for the real-world open-pickup workflow it was designed for, without loosening the check itself.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves — owner-authored PR fixing a live-reported label-propagation gap; no separate issue was filed for this follow-up fix.

Validation

• npm run typecheck
• npx vitest run test/unit/agent-actions.test.ts test/unit/agent-action-executor.test.ts test/unit/agent-approval-queue.test.ts test/unit/queue.test.ts — 1258/1258 pass, including new planner tests (linkedIssues threaded/absent/empty/capped), new executor tests (assigns each linked issue, one failure doesn't affect others, no-linkedIssues means no extra calls), and a round-trip test through the approval-queue's actionParams/pendingActionToPlanned.
• npm run actionlint / npm run test:workers / npm run build:mcp / npm run test:mcp-pack / npm run ui:openapi:check / npm run ui:lint / npm run ui:typecheck / npm run ui:build / npm audit — not run locally for this focused change; relying on CI (validate) for the full gate. Confirmed via grep that AgentPendingActionParams (the type this PR extends) is not exposed via OpenAPI, so no ui:openapi regeneration is needed.
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries — both sides of every new conditional (linkedIssues present/absent/empty, cap hit/not-hit, per-issue assign success/failure) are covered.

If any required check was skipped, explain why:

• This is a narrow, single-concern fix (6 files, no schema/API/UI surface); the full npm run test:ci gate is left to CI per the repo's own established practice for this size of change.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. — N/A, no auth/session surface touched (uses the same installation-token auth the existing PR-assign call already uses).
• API/OpenAPI/MCP behavior is updated and tested where needed. — N/A, confirmed not exposed via OpenAPI.
• UI changes use live API data or real empty/error/loading states. — N/A, no UI changes.
• Visible UI changes include a UI Evidence section. — N/A, no UI changes.
• Public docs/changelogs are updated where needed. — N/A, internal automation behavior only.

Notes

• Root-caused live while investigating a report that gittensor:priority wasn't propagating to contributor PRs the way gittensor:bug/gittensor:feature reliably do.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.96%. Comparing base (90943c9) to head (9ec7491).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4412   +/-   ##
=======================================
  Coverage   93.96%   93.96%           
=======================================
  Files         401      401           
  Lines       36902    36909    +7     
  Branches    13494    13496    +2     
=======================================
+ Hits        34676    34683    +7     
  Misses       1570     1570           
  Partials      656      656           

Files with missing lines	Coverage Δ
src/queue/processors.ts	95.37% <ø> (ø)
src/services/agent-action-executor.ts	97.00% <100.00%> (+0.04%)	⬆️
src/settings/agent-actions.ts	97.75% <100.00%> (+0.03%)	⬆️
src/types.ts	100.00% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.