persist: Poke at a fetch-time assert

[bkirwi]

Motivation

https://github.com/MaterializeInc/database-issues/issues/10097

Description

This assert is failing at part fetch time:

assert!(
    PartialOrder::less_equal(inline_desc.since(), registered_desc.since()),
    "key={} inline={:?} registered={:?}",
    printable_name,
    inline_desc,
    registered_desc
);

It's hard to know exactly what went wrong here based on the evidence in the logs, but, two commits:

• Generally speaking, these two descs should match exactly, because the data was all written together. The only case I can think of where that's not true is incremental compaction, where we patch in a new set of runs. This will normally advance the since, which is fine according to the above check. However, I think it is possible for it to regress the since if we somehow end up doing two incremental compaction runs in parallel, those two runs end up with different target sinces, and the one with the earlier since commits second. Kind of a weird series of events! But anyways now that invariant is enforced more explicitly.
• Even in that case, any data in the batch will be earlier than the overall shard since, since we check that invariant aggressively and early. So any differences here won't actually be visible to any readers, because those readers should be reading at the overall shard since or later. Thus: I have turned the assert into a soft assert; it indicates a problem but not necessarily a user-facing consistency violation, and it's kinder not to brick a shard if we can avoid it.

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).