[fm] Guard support bundle creation with SitrepGuardedInsert.

[mergeconflict]

Wire the support bundle resource through SitrepGuardedInsert:

• impl SitrepGuardedResource for SupportBundle;
• schema: support_bundle_generation on fm_sitrep and the rendezvous_support_bundle_created marker table (migration fm-bundle-resource-deletion);
• support_bundle_create's FM path routes through the combinator, surfacing a stale sitrep as Error::Conflict;
• SitrepBuilder tracks support_bundle_generation, bumping it when the outstanding support-bundle-request set changes; the closed-case carry-forward filter drops fully-satisfied closed cases and keeps those with unsatisfied support bundle requests;
• fm_rendezvous reads the expected generation and aborts the support bundle loop on a stale mismatch; fm_analysis loads existing markers to drive carry-forward; omdb displays the new status fields and generation.

support_bundle_generation and alert_generation are tracked and guarded independently, so a stale generation for one resource aborts only that resource's rendezvous loop.

Context: #10248, builds on #10564 and #10533.

[hawkw]

hmm. similarly to the suggestion I left on #10533, I wonder if we might want to refactor this as separate support_bundle_create and fm_rendezvous_support_bundle_create methods, rather than passing in a "provenance" type that tells the method which behavior to do --- I can't really imagine having code that wants to be able to call support_bundle_create with either provenance dynamically; we're only doing one code path or the other, so it feels a bit nicer to me for them to just be separate methods.

with that said, I realize that (unlike alerts) the provenance enum was already here, so 🤷‍♀️

[mergeconflict]

I had a reason for keeping the switch-on-provenance thing here, but now I honestly can't remember what it was or whether it was a good reason. I'll think about this.

[mergeconflict]

Ok, I messed with this a bit and decided to stop messing with it. The direction it was going, I had three separate SupportBundleCreateParams structs: one for support_bundle_create, another for fm_rendezvous_support_bundle_create, and a third for their shared helper function (which had some super fun trait bounds for the insert query closure)... It was getting ugly, and then my efforts to de-uglify all pointed in the direction of "hey wouldn't it be nice to just switch on provenance."

[hawkw]

Similarly to what we did in #10533, I think that if we're going to split the FM and user-requested support bundle creation code paths into separate functions, it would be nicer to just have the FM one return an error enum that represents these specific error cases more explicitly, rather than an external::Error.

I was going to suggest that we could take the FmRendezvousAlertCreateError type added in #10533 and rename it to FmRendezvousCreateError or something, and remove the string "alert" from the docs/formatted output (we could say the generic "resource" or something instead). But, I realized that support bundle creation also needs to be able to represent "insufficient capacity". I suppose we could do something like

enum FmRendezvousSupportBundleCreateError {
    #[error("insufficient capacity for blah blah blah whatever")]
    InsufficientCapacity,
    #[error(transparent)]
    Create(#[from] FmRendezvousCreateError),
}

or something? I dunno if that's really worth it over just having separate error types...

[mergeconflict]

Yeah, see above... I agree in principle but it's a bit of a pain here in practice, so I'm punting on this.