librarian: plan change management wrt repos, and document compatibility

#4767 and #4766 were both created automatically after #4733 effectively broke HEAD of google-cloud-rust - because the Librarian code change required a config change in google-cloud-rust.

Trying to keep librarian@HEAD working with (all-language-repos)@HEAD all the time is going to be challenging, unless we go to extraordinary lengths to allow duplication of config values etc to allow a smooth migration in every case. There are situations where that's called for, but I don't think it's crucial in this project. In particular, we have the `version` field in librarian.yaml to specify "this is the version I expect to be used for operational purposes".

*Perhaps* the right approach here is to file a P1 issue instead of P0. This could then be addressed by changing google-cloud-rust's configuration, changing both the version *and* the relevant bit of config (for the storage module). The version would be changed to a "current head" style version. Two issues:

- That still assumes we're always ready to adopt HEAD of librarian. That should *usually* be the case, but I wouldn't be surprised to find times where we want to overhaul a language in a way that takes more than one simple commit to fix. Perhaps in that case the "generate at HEAD" check could just be disabled for a while.
- It encourages the use of commit-based versions rather than actual tagged releases of librarian. Personally I prefer the latter, to give more of a fixed point to consider for compatibility purposes. Others may disagree - the Rust team seems to be using commit-based versions without significant issues, for example.

If we *do* expect librarian HEAD to always be compatible with HEAD of all language repos, we should document that. Otherwise, we should plan and document what compatibility we *are* expecting.

Start by reviewing issues #4767, #4766, and #4733 to understand the configuration breakage and the compatibility question around librarian.yaml. Done means agreeing on an expected compatibility policy or change-management process and documenting how versions, repository changes, and temporary incompatibilities should be handled.

Written by the indexing model from the issue text.