fix: drag region BrowserView calculations on macOS

[codebytere]

Description of Change

Closes #28405. This was originally added in #27147, but it turns out that solution masked a different root problem, which was what I later solved in #28268. However, this meant that the previous PR was relying on incorrect assumptions, and would thus offset the bounds too far. This correct it so that all offsetting is handled in a single place for BrowserViews and we can once more safely assume that defaulting to 0, 0 for x, y in the case of no drag regions will produce the desired drag configuration.

Tested with:

• https://gist.github.com/b9c5a45bf59f6ba748041d000414e571
• https://gist.github.com/9dd56c8dae033bcb77cd107259591121
• https://gist.github.com/08f3e56e0a4dc443621bd769e18c7cd6
• https://gist.github.com/c138020abbb7d949608c3c11b1cad253

cc @Kilian

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an issue where drag regions on macOS would be offset incorrectly when no drag regions were set,

[ckerr]

The logic in the PR description makes sense and the PR looks fine, but I wish there was a way to write tests for this.

[release-clerk]

Release Notes Persisted

Fixed an issue where drag regions on macOS would be offset incorrectly when no drag regions were set,

[trop]

I have automatically backported this PR to "13-x-y", please check out #29017

[trop]

I have automatically backported this PR to "11-x-y", please check out #29018

[trop]

I have automatically backported this PR to "12-x-y", please check out #29019