Party state: Invalid when in an instance

After a discussion with @adamhaeger about #1298 (PR #2003), we talked through how party selection works, and what 'valid parties' entail. Since we call `api/v1/parties?allowedtoinstantiatefilter=true`, the list of 'valid parties' is more correctly described as 'parties that can be used to create a new instance'.

That realization exposes a few potential problems in our codebase:
- We run checks to figure out if we should show party selection _before_ displaying a stateless app - without ever knowing _if_ the stateless form potentially concludes in an `InstantiationButton` (thus making it possible to actually create a new instance). Some stateless apps may never really need a 'valid party' when there is no potential for instantiation.
- It might be of interest for apps to ask for a valid party to instantiate _when clicking an `InstantiationButton`_ instead of before ever reaching it. Either via a party-selector component, or switching to the party selector to prompt when clicking the button. Backend code might call APIs based on the currently selected party though, so it should be configurable.
- Most importantly (and the reason I'm putting `quality/debt` on this issue): The way `PartyProvider` wraps everything in our app indicates that any code (at any point in time) might be interested in knowing about the current party, and using that state. However, the current party (and list of valid parties) is stored in a cookie, and never automatically refreshed whenever that cookie changes. It is entirely possible to (and there are use-cases for) switching to another party in a new tab, working on multiple instances (possibly with different apps) at the same time, representing different parties. The current party and the list of 'valid parties' is only relevant when creating a new instance, so our code should not allow keeping that state for longer than that.

Start by reading the PartyProvider and InstantiationButton entry points, then trace how the current party, valid-party list, cookie, and `api/v1/parties?allowedtoinstantiatefilter=true` are used around stateless apps. Compare the party-selector behavior before app display with the proposed behavior at instantiation time; done requires an agreed design for when party state is queried and how changes across tabs are handled.

Written by the indexing model from the issue text.