[NOM-5453] Fix depth handling when chaining passes with different sample counts

[LukPopp0]

Description

A buffer that was freshly allocated and then got no copy has no initialization at all, so the depth AOV takes its default clear value in that one case. The clear is additionally gated on this pass owning an output buffer for that AOV, because the mismatch and the allocation are decided by different conditions: the allocation is skipped when the input bindings and output tokens are unchanged, so without the ownership test the clear would land on the buffer still shared with the previous pass.

In RenderBufferManager::Impl::SetRenderOutputs, the same-renderer test is hoisted into its own local so the depth decision can be stated directly:

const bool sameRenderer = (rendererName == input.rendererName);
const bool multisampleMismatch =
    input.buffer && (input.buffer->IsMultiSampled() != desc.multiSampled);
inputFound = sameRenderer && !multisampleMismatch;
...
if (sameRenderer)
{
    depthInput.texture = HgiTextureHandle();
    clearFreshDepth    = !inputFound;
}

A buffer that was freshly allocated and then got no copy has no initialization at all, so the depth AOV takes its default clear value in that one case:

 HdRenderBuffer* outputBuffer = static_cast<HdRenderBuffer*>(
     _pRenderIndex->GetBprim(HdPrimTypeTokens->renderBuffer, aovId));

 const bool clearThisAov = !foundInput.buffer ||
     (localOutputs[i] == HdAovTokens->depth && clearFreshDepth && outputBuffer);

Changes Made

• When the renderer is the same, never copy the chained depth into the pass's own buffer. A reused buffer already holds valid depth, and on a multisample mismatch a fresh buffer is allocated, so the copy would only flatten sub-pixel depth.
• Clear that fresh depth buffer. It is the one case where a buffer receives neither a copy nor pre-existing depth, so without the clear the pass depth-tests against undefined contents on the first frame and after every resize.
• Add tests for the various cases or matching or mismatching multisampling values between passes (state comparison, no image comparison).
• Only clear a buffer the pass owns. The mismatch that sets the clear and the allocation of the fresh buffer are gated on different conditions, so a pass that toggles its own MSAA setting while its bindings stay identical would otherwise clear the depth buffer it is still sharing with the previous pass.
• Document the buffer sharing rules in docs/renderbuffermgr.md, which described reuse unconditionally and mentioned neither the same-renderer requirement introduced by [NOM-5453] Allocate fresh depth buffer when pass's sample count differs from the chained input #184 nor the matching-sample-count requirement.
• Add a FIXME next to the sameRenderer test recording that chaining across render delegates still copies the depth.

Behavior change

In the same-renderer, mismatched-sample-count case the previous pass's depth is now discarded rather than copied forward, so geometry in the second pass is no longer occluded by geometry from the first. This is intended for overlay passes such as the ViewCube, and is what docs/renderbuffermgr.md now describes.

Known limitations

• Chaining across render delegates still copies the depth, because that copy is the only mechanism carrying depth between them. It therefore still binds depth as a sampled texture and can still fail on WebGPU. Marked with a FIXME in the code.
• A pass that toggles its own MSAA setting while its input bindings and output tokens stay identical keeps sharing a buffer whose sample count no longer matches its attachments. This PR stops the destructive clear on that path but does not fix the sharing; that needs the multisample state folded into the somethingChanged comparison.

Testing

Test Configuration

• Platform(s) tested: macOS 15
• Build configuration(s): Debug/Release
• Render delegate(s): Storm (Metal)
• OpenUSD version: 26.05

Tests Performed

• Existing unit tests pass
• Added/Updated unit test(s) for the changes
• Tested on multiple platforms
• Tested with different render delegates
• Performance testing (if applicable)

Documentation

• Code is self-documenting / well-commented
• Public API changes are documented with Doxygen comments

Checklist

• I have signed the Contributor License Agreement (CLA) (Corporate or Individual)
• My code follows the project's coding standards
• My changes generate no new warnings or errors

[hodoulp]

As human reviewer, the code is fine & the logic is improved and unit tests validate the fix. That's fine.
Using coding models, one mentioned that everything is fine. Another mentioned a potential bug, I'm currently digging in the explanation i.e., "the new depth clear can be applied to a buffer this pass doesn't own" & "Undocumented new behavoir". Stay tuned.