RawProgress bridge: support guarded capture/commit for an explicitly targeted inactive profile destination

[Shilvia-i]

Hi, and thank you again for the raw-progress bridge and recovery work.

I am sorry to open another issue after our earlier bridge request. To avoid
raising requirements piecemeal, we first completed and
tested all provider-independent consumer-side work we could. This issue is
intended to consolidate the remaining known RitsuLib dependency into one
request.

Progress Bridge now has a live-verified Vanilla-to-Modded flow using the
active Modded progress document. The remaining bidirectional use case is
Modded-to-Vanilla: while mods are loaded, the Vanilla profile is an inactive
destination.

The current IRawProgressCommitBridge contract is intentionally scoped to
the active progress document. CaptureAsync has no destination selector, and
CommitAsync conditionally commits that active document. We do not want to
bypass the bridge by editing the inactive Vanilla file directly, because that
would lose the exclusive save window, source/destination generation checks, durable
replacement, Cloud batch/read-back verification, and recovery journal.

Would you be open to a targeted-destination extension (a separate interface
would be fine) that can safely capture and conditionally commit an explicitly
selected profile/environment even when it is inactive?

The consumer-side requirements we currently fail closed on are:

• explicit profile ID and Vanilla/Modded destination selection;
• a versioned, capability-advertised stable public contract, including
  supported schemas/environments and document/recovery limits;
• capture of the exact Modded source and inactive Vanilla destination generations;
• conditional rechecks of both generations inside the same exclusive save
  window as the commit, so a stale prepared proposal is never committed after
  the Modded source has changed;
• schema-21 raw JSON and unknown-property pass-through;
• the game's durable local replacement and Cloud save batch;
• direct Cloud read-back verification;
• owner-scoped local recovery journals with restore/discard support;
• no replacement of the active Modded in-memory progress state when the
  inactive Vanilla destination is committed;
• structured evidence distinguishing no mutation, verified commit, conflict,
  and recovery-required outcomes.

A conceptual shape could be:

public interface ITargetedRawProgressCommitBridge
{
    TargetedRawProgressBridgeAdvertisement Describe();

    ValueTask<RawProgressReadResult> CaptureAsync(
        RawProgressDestination destination,
        CancellationToken cancellationToken = default);

    ValueTask<TargetedRawProgressCommitResult> CommitAsync(
        TargetedRawProgressCommitRequest request,
        CancellationToken cancellationToken = default);
}

public sealed record TargetedRawProgressCommitRequest(
    RawProgressDestination Source,
    RawProgressGeneration ExpectedSourceGeneration,
    RawProgressDestination Destination,
    RawProgressCommitRequest DestinationCommit);

This is only a discussion sketch; we would follow whatever API shape best
preserves RitsuLib's existing safety model. We already have synthetic
consumer pipeline, guarded in-game preparation/confirmation UI, and
synthetic tests for capability negotiation,
profile/environment binding, validated schema-21 proposal construction,
one-shot confirmation, fresh candidate comparison, source and destination
conflict refusal, Cloud/read-back evidence, active-state isolation, and
recovery-required outcomes. The UI currently receives an explicit
provider-unavailable capability and cannot arm the reverse action. No
inactive-profile write has been attempted.

Targeted recovery inspection, restore, and discard may reuse the existing
recovery contract if it can identify the inactive destination and preserve
active-state isolation; we do not require separate methods if the existing
shape can safely cover this case. For live consumer acceptance, is there also
a maintainer-approved test or fault-injection path that can produce an
authentic retained recovery journal on a disposable profile without directly
editing game or recovery files?

Is this use case something RitsuLib would be willing to support, or is there
another official in-process path you would recommend?