fix(l1, l2, levm): move loc_report.json to loc_report.json.old even when there a restore-keys is used.

[lima-limon-inc]

Even when there is no cache-hit, the file is fetched. If it came from the restore-keys directive, it doesn't count as a cache-hit even if the file is fetched.

Motivation
Show LOC diffs in the different slack channels.

Description
This description was taken from this comment: #1433 (comment)

We are saving the log_report.json file on a cache entry that has as key loc-report-${{ github.ref_name }}.
github.ref_name is the name of a branch not a commit hash. That name is not "main" but rather the name of the PR it came from. In this case ci-diffs.

What's the problem with that?
If the branch names don't match EXACTLY, the cache fails. HOWEVER, we have a restore-keys as a backup (here: https://github.com/lambdaclass/ethrex/blob/main/.github/workflows/daily_reports.yaml#L124-L125).

restor-keys is a backup that acts like a sort of regex. It tells github-cache "Hey, seen as you failed fetching that EXACT key, give me, as a backup, a value that matches the following prefix". That prefix should match everytime, since every key we generate uses that exact same prefix.

So what's the problem? The problem is that we are only changing the file name IF there is a cache hit aka this if: https://github.com/lambdaclass/ethrex/blob/main/.github/workflows/daily_reports.yaml#L132. So, once again, what's the problem? We are getting a cache hit everytime, we either get it with the exact key or using the restore-keys as a fallback.

And there is the problem, if the value is fetched using restore-keys, it doesn't count as a cache hit.
This behavior is described here: https://github.com/actions/cache/blob/main/README.md?plain=1#L129.

That would also explain why the script worked while I was working on this PR: I was always on the same branch, so it was always a cache hit, it was never using restore-keys. However, when the cron job is executed, it probably fails every time and ends up using the backup.

That is also strange, one would think that it would end up using "main" branch as a key name. My hunch is that it uses commits coming from PR's, so it's maybe using those PR branch names for keys.

I'm gonna create a new PR for it to be merged on Tuesday, so we can see the difference in output and check that this indeed is the issue.

No associated issue number

[lima-limon-inc]

Ideally, this should be merged on Wednesday. So we can see the bot's output on monday and tuesday, and we let it store those values in the cache. Just in case.