Best practice for storing CI build logs in Loki?

When using Loki to store logs from CI build jobs, imagine for example Jenkins jobs or Github actions. The use cases differ quite a lot from server logs.
The main difference is one often wants to associate a single log stream with a specific job_name + job_number, rather than a specific node or server process over time. Which leads to a few questions:

Natural instinct would be to use job number as a Loki label.

But when reading Best practices | Grafana Loki documentation, it describes dynamic labels to be bad practice. Job numbers though, are naturally dynamic and ever growing.

The primary use case of looking at such build logs is to look at one job at a time. So most queries will only ask for single job_nr label. Querying several job_nr simultaneously is more of an edge case only performed rarely by administrators. So the problem, described in the article above, of loading several chunks will not really apply?

Build logs also tend to be very high volume in short time frames. Meaning they will often be in the size range of chunk_target_size even for a single job.

As job numbers naturally grow together with time, they will be phased out over time so given one time range there will not be such a big overlap either and even if the label.

Could one then say that, under such circumstances, job-numbers is an exception to this rule?

The burst nature of these logs have also lead to some problems where it is not possible to see the whole log in Grafana if more than 1000 entries are logged in under 1sec. The older logs button then skip one whole second. Is this a bug or known limitation or am i perhaps using it wrongly?

Querying anything in loki requires knowing start and end timestamp of the job. This isn’t such a big issue but would be nice-to-have if it was possible to avoid this, since job numbers are otherwise quite natural unique identifiers, if one were to use labels.