fix: cherry-pick from forks, finally

[lishaduck]

As often promised, this cherry-picks a bunch of PRs from the @lowlighter repository.
I've reviewed them manually but haven't had experience with any of the listed bugs myself, so I selected what seemed to be the best patch from among the PRs. I took a look at the obviously Claude Code/OpenClaw/etc PRs as well, but did not attribute most of their authors as they didn't seem to contribute anything unique that a human hadn't already written.

• fix: notable not showing users for user-owned repositories lowlighter/metrics#1723
• Fix: Cannot destructure property 'author' of 'undefined' lowlighter/metrics#1739
• WIP: Fix recent languages after GitHub API change (Cannot destructure property 'committer' of 'undefined') lowlighter/metrics#1754
• Fix event parsing in activity plugin lowlighter/metrics#1760
• Fix: Migrate Achievements plugin to Projects V2 API and improve Habits plugin error handling lowlighter/metrics#1769

AI Slop PRs left unattributed

• fix(habits): add null check for commit author property lowlighter/metrics#1778
• fix: add null checks and correct API method for activity plugin lowlighter/metrics#1781
• fix: migrate projects plugin from deprecated Projects (classic) to Pr… lowlighter/metrics#1782
• fix: add optional chaining to wakatime template to prevent rendering … lowlighter/metrics#1783
• feat(plugins/notable): add plugin_notable_organizations_skipped param… lowlighter/metrics#1788
• fix(habits): guard against null commit entries in PushEvent payload lowlighter/metrics#1807

Closes #21.

CC: @dkhokhlov @austenstone @EndBug @oddstr13 @felipecrs @ferferga
Can I get a one or two of y'all to test this branch and make sure it works?

[oddstr13]

Please keep commits intact.

At the very least, keep one commit per contributing person.

I am not happy with the way attribution is getting squished here.

I won't be testing this PR, as I decided it wasn't worth my time to figure out the new errors that showed up (and caused failure email notifications to be generated), and as such disabled it on my profile a while back.

[oddstr13]

Ideally, you would merge in the individual branches that you are cherry-picking from here, keeping all commits with their original commit info. GitHub has instructions for how to merge a commit on the command line, and these instructions can be used to merge changes even tho a particular tree/PR isn't targeted at your own repository.

It is also a good idea to link back to the specific PRs that are included in a combination PR such as this one.

For example, my changes exist here; lowlighter#1754

This helps maintain the context of how and why changes are made, along with who and what comments it has received.

[lishaduck]

I am not happy with the way attribution is getting squished here.

I wasn't pleased with squashing the attribution either, but most of the PRs to upstream either a) overlap with a different PR or b) contain multiple bug fixes (usually both). Given there wasn't much hygiene there, I didn't think anyone would mind much on that point.

Clearly that was an incorrect assumption. I'll pull out your branch and try to merge it separately. Can you check #25?

Please keep commits intact.

I'm happy to keep original authorship, etc, but this repo is using squash merging, so the original commits will end up modified. I hope that's not a problem to you, but most PRs aren't atomic and I value bisection.
I'm also personally far more comfortable rebasing than merging There weren't any conflicts after some finagling, so I just went ahead and merged; it'll get squashed in the end.

I won't be testing this PR, as I decided it wasn't worth my time to figure out the new errors that showed up (and caused failure email notifications to be generated), and as such disabled it on my profile a while back.

No problem! I'm in the same boat, hence the request for testers.

It is also a good idea to link back to the specific PRs that are included in a combination PR such as this one.

Oh, I have them all written down but didn't post them. Silly me 🤦🏻‍♂️ Added them to the description.

[oddstr13]

I think my branch has decently clean commits for the different bits, and thus a perfect candidate for proper cherry-pick, just discard whichever overlap with the other PRs. I know some of my changes ended up being duplicates that I didn't see before after the fact (xz-utils for example).

My branch wasn't intended as a merge-ready PR, but a "this works for me", if the repo had been active, I would've made multiple PRs (cherry-picking from my soft-fork branch – I usually name that one odd-choices as I did here 😅)

My main concern is the authorship info (for git blame), and not the commit hashes – I relatively regularly do rebase and/or squashing myself.
PR/commit references in commit messages is sufficient for when squashing things down, but in general at lest one commit per author would be preferable, where at all possible.

The main issue that I reacted to, is that all authors are attributed for all the changes, and there is no way to tell who did what.

I've worked in codebases where a large part of the git blame is "Release x", where over half the code in the project has been changed in a single commit with no additional context, which is very far from ideal.