trunk shadow changes: com.unity.probuilder

[pets-svc]

This PR contains changes made to the trunk copies of com.unity.probuilder and com.unity.probuilder.tests.

This usually means that breaking changes has landed in the trunk Editor, necessitating matching changes to your package code. trunk is therefore currently running CI tests with the modified shadow package instead of your real package. You must integrate these changes into your package (while maintaining compatibility with older versions of Unity supported by your package), release a new version, and land the new version in the editor manifest before the Package RC deadline, as your package otherwise will not be compatible with the released Editor.

The bot commit was created on top of the package release commit. You may need to cherrypick the commit to a freshly created branch.

Is this automation useful? Let us know on #devs-pets, where you can also ask any question you might have about shadow packages or this automation.

Note: The shadow-package/com.unity.probuilder branch may be force-pushed by automation at any time. If you want to make changes before landing this PR, create your own branch (and PR) to avoid automation overwriting your changes:

git fetch origin shadow-package/com.unity.probuilder:mybranch
git checkout mybranch

If further changes are made to the shadow package on trunk, this PR will be updated if still open, or else a new PR will be opened.

[cla-assistant-unity]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[u-pr]

💡 Harness Review

The import-time guard prevents the original null dereference but leaves cached toolbar controls unable to recover once the UXML asset becomes available.

_{Reviewed commit 8f6fdbb}

_{🤖 Helpful? 👍/👎}

[u-pr]

When the UXML load fails during the import-time state this change is handling, RefreshAvailableActions has already created and cached m_ActionButtons. Bind stores each action but does not wire it up while uninitialized; subsequent refreshes only hide/show those instances, and UpdateToolbar reaches this early return without ever retrying Bind. Thus opening the horizontal or vertical toolbar after the asset database recovers leaves empty, non-clickable controls for the lifetime of that overlay instance. Retry and complete binding for cached buttons once the template is available (or recreate them); grid items already recover because BindItem calls Bind again.

_{🤖 Helpful? 👍/👎}