Fix KeyError when GitHub repo move response lacks full_name

[HimasreeKolathur24]

This PR fixes a crash in the GitHub repository move detection task that occurred
when the GitHub API redirect response did not include the full_name field.

Previously, the code assumed full_name was always present and raised a
KeyError when it was missing. This PR makes the logic more defensive by:

• Safely checking for the presence of full_name
• Logging a warning when it is missing
• Gracefully handling the repo move without breaking collection

This improves robustness when GitHub returns partial or unexpected redirect
metadata.

This PR fixes

Fixes #3621

Notes for Reviewers

• This is a defensive bug fix only
• No schema, migration, or data changes
• Existing behavior is unchanged when full_name is present
• Prevents GitHub collection tasks from failing due to incomplete API responses

Signed commits

• Yes, I signed my commits.

[MoralCode]

Overall I think the core change here is a good start, but

1. id like to understand the reason why the API can return data without full_name as that will help inform how we handle things
2. there are a lot of unrelated formatting changes in this PR that make me a little nervous about the possibility of accidentally changing things. Did those come from your editor? or were they somehow derived from our own existing linter rules?

[HimasreeKolathur24]

@MoralCode,
I’ve addressed the feedback and pushed updates. Thanks for taking the time to review.

[MoralCode]

All the specific code feedback has been addressed, sure. But im still unsure what causes this full_name field to be missing in the first place. Without understanding that, its very hard to evaluate whether this is the correct solution to the issue.

I would like to see more information posted in the underlying issue that provides a root cause analysis for the issue before this pr can move forward

[HimasreeKolathur24]

@MoralCode,
I’ve added some context to the issue about how the redirect URL is currently being used and my understanding of when this occurs. Thanks for pointing this out.

[MoralCode]

I did some digging into this and came up with a different PR to help confirm my theory for why this is happening.

#3670

Can you take a look and close this PR if you think that is a better solution?

[MoralCode]

This is currently waiting on a re-visit after evaluating the logs of this failure after the next release