Ignore sub-sub-issues when syncing tasks to Notion

[mzeier]

Summary

The GitHub → Notion sync only supports a single Milestone → Task hierarchy ("1 level of sub issues"). When an issue is a sub-issue of a task (a sub-sub-issue), its parent is a task rather than a milestone, so _find_task_parents finds no milestone and the issue lands in Notion as an orphaned task with no milestone relation. This is the breakage hit on thunderbird/platform-infrastructure#384.

This makes the sync ignore those sub-sub-issues instead of choking on them, so milestones don't have to be manually restructured to flatten the hierarchy.

Approach

• New Issue.deeply_nested flag (default False, so other trackers like Bugzilla are unaffected).
• GitHub._is_deeply_nested_subissue detects the case during issue parsing: the issue has a parent whose issue type is neither Milestone nor Epic (i.e. a regular task). An untyped parent is treated as valid, matching the conservative behavior already used in _fixup_issue_milestone_with_parent.
• synchronize_single_task skips and logs these, covering both the project sync and label sync paths.

Notes / scope

• Ignore-only — no GitHub mutation. Unlike the existing hierarchy fixups, this does not remove any sub-issue links on GitHub. The nesting stays intact for internal tracking; it just doesn't flow to Notion.
• Existing orphans are left untouched. Any sub-sub-issues already created as orphan tasks in Notion won't be auto-removed; they simply stop receiving updates. Happy to make the filter self-heal (archive existing orphan pages) if that's preferred.

Tests

• test_is_deeply_nested_subissue — unit coverage of the detection (no parent / milestone / epic / untyped parent / task parent).
• test_deeply_nested_subissue_ignored — end-to-end: a sub-sub-issue picked up via the sprint board is not written to Notion.
• Full suite + task lint / task format --check pass.

[mzeier]

@kewisch @kellymcs01

This PR would address something like https://github.com/thunderbird/platform-infrastructure/issues/384 which has sub-sub issues.

The sub-sub issues are internal-to-the-team details and don't need to propagate to Notion - this just ignores them on the sync, leaving them intact on GitHub.

For @kellymcs01, this should mean no need to manually break #384 apart into more milestones.

[kewisch]

I'm not sure where we left off on this. We should only have sub-sub-issues if they belong to a task that can be completed within roughly one sprint. Then the question is do we really need sub-sub-issues in that case, or would a checklist on the individual task suffice? I'm worried we're getting too granular. Tasks are already kind of internal-to-the-team, and with a cycle of 1 or 2 weeks, breaking tasks down further could create some overhead.

[mzeier]

I'm not sure where we left off on this. We should only have sub-sub-issues if they belong to a task that can be completed within roughly one sprint. Then the question is do we really need sub-sub-issues in that case, or would a checklist on the individual task suffice? I'm worried we're getting too granular. Tasks are already kind of internal-to-the-team, and with a cycle of 1 or 2 weeks, breaking tasks down further could create some overhead.

This is specifically internal-to-the-team and shouldn't be externally consumed. We can used "Fixes" syntax to automatically close sub-sub-tasks (we can't with checklists).

The intent is to ignore these outside of GitHub and not expose them into Notion.