fix(review): linked-issue label propagation is disabled everywhere + ownership check would block it anyway

[JSONbored]

Context

While investigating a contributor report that PRs sometimes don't carry the same points-bearing label as the issue they close, I traced the full label-decision path in this repo:

• resolvePrTypeLabel() (src/settings/pr-type-label.ts:142-165) decides a PR's gittensor:bug vs gittensor:feature purely from deriveKindFromTitle() — a regex on the PR's own conventional-commit title prefix — unless linkedIssueLabelPropagation is enabled with a matching mapping. gittensor:priority can only ever come from a propagation match; it is never inferred from title, changed files, AI output, or existing labels.
• I queried production D1 directly (repository_settings.linked_issue_label_propagation_json): it is "{}" (propagation disabled, zero mappings) for JSONbored/gittensory, JSONbored/metagraphed, and JSONbored/awesome-claude. Neither repo's own .gittensory.yml sets it either — both fall through to the same disabled default.
• Net effect: on every gated repo, a PR's label is currently 100% independent of the label on the issue it closes. gittensor:priority (1.75x) can never be auto-applied to a PR at all today.
• Even if propagation were switched on as-is, fetchLinkedIssueLabelsForPropagation() (src/review/linked-issue-label-propagation-fetch.ts:65-77) only trusts a linked issue's labels when the PR author opened that issue or is one of its assignees. Our issues are almost all authored by @JSONbored for open community pickup, and assignee coverage is only ~106/150 open issues on gittensory and ~40/170 on metagraphed — so this ownership check would silently defeat propagation for most real contributor PRs, falling back to title-classification with no visible signal that it happened.

Requirements

1. Decide + enable linkedIssueLabelPropagation (exclusive mappings: gittensor:bug→itself, gittensor:feature→itself, gittensor:priority→itself) for JSONbored/gittensory and JSONbored/metagraphed.
2. Reconcile the ownership check in fetchLinkedIssueLabelsForPropagation with our actual workflow (maintainer-authored issues open for any contributor to claim, rarely formally assigned). The abuse case that check guards against — a contributor linking someone else's issue to steal its label — doesn't really apply when the issue is maintainer-authored and open to anyone. Options to weigh: loosen the check specifically for point-bearing labels, add a repo-level config toggle, or substitute a different anti-abuse signal that doesn't require formal GitHub assignment.
3. Add observability (a log line / structured event) for "propagation enabled but returned [] because the ownership check failed" so a future "PR didn't inherit the label" report is diagnosable without a full source read.

Deliverables

• Config change enabling propagation on both repos (.gittensory.yml or dashboard settings).
• A code change to the ownership-check semantics (or an explicit written decision + doc note if it's staying as-is).
• A log line / structured event on propagation-skipped-due-to-ownership.
• Test coverage for whatever ownership semantics land.

Expected outcome

A PR that closes an issue reliably inherits that issue's point-bearing label (bug/feature/priority), without depending on the contributor wording their commit title a particular way, and without a maintainer having to notice-and-manually-relabel after the fact.

Non-goals

• Not about the ~81 mislabeled metagraphed issue labels themselves — tracked separately.

[linear-code]

JSO-2863