Place overlay debug panels on the side that fits

[vibhor1102]

Summary

Fixes #850.

This PR makes horizontal debug/result panels choose a side around the floating overlay buttons instead of always assuming that the panel can open to the right.

It applies to:

• the main running toolbar live debug panel
• the try-event live debug panel
• the try-image-condition result/threshold panel

Behavior

Right-side placement remains the default. The panel flips left only when all of these are true:

• the panel cannot fully fit on the right side of the button cluster
• the panel can fully fit on the left side
• the left side has more available room than the right side

When the panel flips left, the button cluster remains the user's visual anchor. The overlay window shifts left so the buttons stay where the user placed them.

Other Details

• Placement is rechecked after the user releases the move button, not continuously during drag.
• The stored overlay position remains the logical button-cluster anchor, not the shifted left-panel window edge.
• The panel is reordered inside the same rounded CardView rather than split into a second overlay window.
• Debug separators move to the inner edge when the panel is on the left.
• Try-event and try-image-condition placement calculations now use the actual panel widths from their layouts.

Animation Caveat

This improves the clipping/placement logic and reduces a few right-side assumptions in the transition path. The resize animation may still benefit from maintainer-side visual tuning on a real device: when the panel is on the left and the buttons are anchored on the right, Android's layout-change transition can still feel like it is folding from the larger debug panel instead of perfectly from the button anchor. I am calling this out because the mechanical placement behavior is covered here, while the final motion polish is much easier to judge with live overlay feedback.

Validation

• ./gradlew.bat --no-daemon --max-workers=3 --console=plain :core:common:overlays:testFDroidDebugUnitTest :feature:smart-config:compileFDroidDebugKotlin :feature:smart-debugging:compileFDroidDebugKotlin

[vibhor1102]

More information about animation caveat: Since i just coded the feature using Codex and lack code knowledge myself, i am unable to fix the transition issue caused when pausing. Otherwise, i hope this feature is an overall non disruptive little addon, fit for addition to the main app as well.
:-)

[vibhor1102]

Small related note while testing the 4.0.0 beta overlay behavior: this PR also fixes a remaining edge-position restore issue from #852.

#852 fixed the data-source side by making OverlayMenuPositionDataSource distinguish missing preference keys from valid zero coordinates. So positions like (x = 84, y = 0) can now be loaded correctly.

The remaining problem is in OverlayMenu.loadMenuPosition(...): current master still checks savedPosition.x != 0 && savedPosition.y != 0 before applying the loaded position. That means a valid top-aligned position with y = 0 is loaded, then rejected by the caller, and the menu falls back to the default centered placement. This is why, in 4.0.0-beta01, placing the overlay at the top works until the overlay is hidden/restored or recreated, such as when opening scenario settings or rotating the screen.

This PR removes that caller-side zero rejection as part of the menu anchor-position work, so top/left/top-left saved positions are restored correctly here.

If this PR does not get merged as-is, I think a small follow-up fix would still be needed for that specific issue: treat any non-null loaded position as valid in OverlayMenu.loadMenuPosition(...), because the data source already handles the missing-position case after #852.