figure out locking/regenerate-imports semantics for bot

cargo-vet has a mechanism where you can import `audits.toml` files from other projects (e.g. "I peer with mozilla, so I import their audits.toml").

cargo-vet was originally designed on the premise that humans would be running it on their local machines without `--locked` so we can opportunistically update imports. A mechanism was also added to minimize the churn for this: the imports.lock file only contains *required* information. We GC anything that wasn't (seemingly) necessary to get things audited.

CI would then run `--locked` which only used the imports.lock to avoid spurious breakage.

However this limits the capacity for ci/bots to know about additional useful information. In the simplest case there may simply be a new import that covers a new requirement. More subtly it may just make a requirement simpler (smaller diff). Even more subtly an import may introduce a `violation` and we won't know, and may even suggest audits that overlap with that violation!

Also the bot is actually *better* poised to update imports, as it's more trustworthy than "some human pushed a commit with imports.lock updated, trust me it's legit". Clearly the bot should have a mechanism for pulling in imports and updating them.

Before the imports GC thing I had suggested it periodically opening dependabot-style PRs, but now I think it would have to just surreptitiously insert them as part of other ops. Although maybe a cron job for checking violations is merited.

Start by reading the described cargo-vet import flow, including audits.toml, imports.lock, and the --locked behavior. Map how CI and the bot currently handle imports, then define what bot updates should do for new coverage, simplified requirements, and violations. Done means the locking and regenerate-imports semantics are documented and an implementation path is agreed.

Written by the indexing model from the issue text.