Browser indeed should only be added in content or layout page, and not on the partial page in an ideal scenario. But the partial is allowed to have its own browser component - that is not restricted.
The limitation here is a logical one, from my perspective, rather than a Wppler bug. Let me know if I am going in a different direction than your requirement.
When you create a partial, it could be used in content/layout A or B or X or Z. The partial has no way to know where it is going to be used.
So, without that knowledge, there is no way to populate dynamic picker UI when editing a partial page.
One potential solution could be to just show all the bindings from all project pages - content or layout - but it will just cause more confusion, specially in NodeJS because all content pages are just under "content" object. (In ASP .NET & PHP, there are route objects which provide some distinction.) But because the items could have same names etc, it would be a nightmare.
In one of our projects, where we have numerous partials (you know which one ) , and use dynamic bindings from content pages - we have to make sure explicitly that all content pages that are going to use that partial have SC or other components with the same name & data structure, so that the partial bindings can be evaluated on runtime to show correct data.
This is a manual process to setup in both Partial and Content/Layout pages.
If you absolutely need to access bindings via picker, copy-paste partial code into the content page of your choice, setup the bindings etc, then cut that code back into partial page.