`bulk-disseminate` Actions will fail if more than 256 submission candidates are found

[rhigman]

"A matrix will generate a maximum of 256 jobs per workflow run"

If the run-script stage of any bulk-disseminate Action finds more than 256 works which need to be disseminated based on the Action's inclusion criteria, the run will fail and none of the works will be disseminated. This is because the list of relevant work IDs is passed to a GitHub Actions matrix to create one submission job per work.

Additionally, due to the fact that the list of work IDs found by run-script is not output anywhere (e.g. in logs or artifacts), it's not possible to make up for the failure by disseminating the required works in a more manual fashion.

At present scale, this will rarely be an issue; in most cases, it would require the total number of works produced in a month by all publishers opted-in to a specific dissemination platform to exceed 256 (the current average is closer to 10). However, this did occur in a run of cr-bulk-disseminate, after a bulk database update caused ~6000 works to show up as having been updatedWithRelations within a single dissemination period.

(The update itself wasn't actually one which warranted mass resubmission of metadata anyway; we should consider how to handle similar future updates without unnecessarily overloading distribution platforms.)

Failure report:

[rhigman]

Could investigate removing matrix and instead using GitHub API to trigger a new workflow run for each work (instead of a new job within a single run): use cron workflow to do run-script check.

[rhigman]

Now slightly mitigated by obtain-new-ids (formerly run-script) writing out a "List of IDs found:" in the logs (added under 506bd4d).

Could add a similar log line to obtain-locations, which is liable to hit the same issue (example).