Default --since to latest GitHub Release's tag instead of publication date

[consideRatio]

With #125 we started relating to the latest GitHub Release, and specifically its associated publication date. The motivation for this was described by @choldgraf as:

This is more reliable in case the repository is using git tags for things other than releases of the current repo (e.g., if it's a monorepo doing many releases)

I was thinking it could be even better to relate to the GitHub Release's tag because a GitHub Release could be retroactively created for some older tag, and would then incorrectly indicate what is relevant to relate to. So, this is what this PR proposes.

By doing this, we also avoid an error message where the latest GitHub Release's publication date was tested by github-activity as a git reference before being treated as a date.

Before this PR

github-activity --heading-level=3
Auto-detecting latest release date for: sensmetry/sysand
Running command: gh release view -R sensmetry/sysand --json name,publishedAt
Using release date for release v0.0.11 on 2026-04-30T11:14:12Z

!! GitHub error: No commit found for SHA: 2026-04-30T11:14:12Z

Running search query:
repo:sensmetry/sysand


Found 10 items, which will take 1 pages
Found 14 items, which will take 1 pages
### main@{2026-04-30}...main@{2026-05-06}

After this PR

github-activity --heading-level=3
Auto-detecting latest release tag for: sensmetry/sysand
Running command: gh release view -R sensmetry/sysand --json name,publishedAt,tagName
Using release tag v0.0.11 for release v0.0.11 published at 2026-04-30T11:14:12Z
Running search query:
repo:sensmetry/sysand

Found 12 items, which will take 1 pages
Found 15 items, which will take 1 pages
### v0.0.11...main@{2026-05-06}
...

AI disclaimer

I've used codex (GPT 5.5) as a tool for verification of my hypothesis of what was going on, and some code changes in this PR. Is there a policy about this within executablebooks to be aware about AI use?

[choldgraf]

nice! if I understand, you're basically saying that we should use the git ref associated with the release, rather than the technical date the release is published. And that is because the author might update the git ref which will update the tag but not the "published" date. Is that right?

And re: llm stuff, there's no formal policy in executablebooks. My 2 cents is that I care more about the thought and care a person put into the PR, regardless of what tools they use. I will tend to put less time into (or dismiss) PRs that are obviously not thoughtful (e.g. obvious AI slop, code that doesn't make sense in a pretty clear way, etc regardless of whether an LLM was used). Other than that I want people to use the tools they need to meet their goals in a sustainable way to them.

[consideRatio]

if I understand, you're basically saying that we should use the git ref associated with the release, rather than the technical date the release is published. And that is because the author might update the git ref which will update the tag but not the "published" date. Is that right?

Ah i wasnt considering a changing git ref for the same github release, but that is a thought as well hmmm. I was thinking that the git tag and git relesde date may be out of sync, and that it then better to relate to the git ref for comparison. For example, you push a git tag, then commit more to main, then a week later get the github release out referencing the tag.

[choldgraf]

This looks good to me! I just have one question to confirm w/ @consideRatio :

Is there always a git tag for a release? If so then I think this is fine

[consideRatio]

Is there always a git tag for a release?

At least for a non-draft release - yes! And we fetch the latest non-draft non-pre-release release - so we are good!

[consideRatio]

Thank you for the swift review @choldgraf!!