Cache entry from default branch considered out of scope for reusable workflow run on tag

According to Restrictions for accessing a cache:

Workflow runs can restore caches created in either the current branch or the default branch (usually main).

I have a reusable workflow that is called from a workflow that runs on a tag ref. It's not finding the cache entry from the default branch (main in my case).

##[debug]No matching cache found for cache key 'cache-trivy-2024-10-29', version 'cfdc2bcf67bb1c3559bbfba62a7ed98abe2868ecc65f79ee627e58280adbf4d3 and scope refs/tags/nightly/20241028.1. There exist one or more cache(s) with similar key but they have different version or scope. See more info on cache matching here: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key 
##[debug]Other caches with similar key:
##[debug]Cache Key: cache-trivy-2024-10-29, Cache Version: 07dc9f6516584e901e644e11f92897f94dbdb6b82f1dda2bb2c3e7fd20bb931a, Cache Scope: refs/heads/main, Cache Created: 2024-10-29T05:13:41.6566667Z

Both workflows run on ubuntu-latest, so this should not be a cross-OS issue.

Start by reproducing the reported reusable-workflow run on a tag with an ubuntu-latest cache created on the default branch, using the debug output and cache-matching documentation as reference. Trace how the cache scope is selected for tagged reusable workflow runs. Done means the default-branch cache can be restored when the key and runner environment match.