Open the vendored MEOS-API refresh instead of failing the schedule

[estebanzimanyi]

The drift check regenerates vendor/meos-api/ and fails when it differs from the committed copy. MEOS-API master moves most days, so the daily scheduled run fails most days: every scheduled run of the last twelve days fails, and refreshing the vendored copy clears it only until master moves again.

The failure is also unaddressable where it fires. A scheduled run has no author, and neither has a push already made, so the message asking someone to run make vendor-meos-api reaches nobody.

This makes those runs open the refresh pull request themselves, carrying the diff, and update it while the difference stands. A pull request that changes the vendored copy or the target that writes it still fails, where its author is there to act; the run reads which paths the pull request changes against its base, so a pull request that changes only this workflow reports the drift instead of failing on a staleness it did not cause and cannot be asked to fix.

MobilityDuck handles the same class of failure this way: meos-surface-refresh.yml opens a refresh pull request on drift, and it carries no per-commit gate that red-lights unrelated work.

Two details the mechanism depends on:

• add-paths stages only what it lists, so it names every path make vendor-meos-api writes; an omitted one is regenerated and then silently discarded;
• the action reuses its branch, so a later run updates the open pull request rather than opening another.

The job commits to a branch and opens a pull request, so it declares contents: write and pull-requests: write rather than relying on the repository default.

Future: pull request CI does not exercise a scheduled job, so a green check here does not prove the new leg. Proving it takes one gh workflow run vendor-drift.yml, and an inspection of the file list of the pull request it opens.