Infinite render loop in <PlaceOverview> #305

Context:
We encountered a critical infinite render loop when using <PlaceOverview> (and <PlaceDataProvider>) from @googlemaps/extended-component-library in a React application. This occurred in a Maps JS API documentation demo: https://github.com/googlemaps-samples/js-api-samples/tree/main/samples/rgm-college-picker

Steps to Reproduce:

1. Aggressively limit the GetPlaceRequest quota for an API key in the GCP Console (this has been done on our documentation API keys to prevent scraping).
2. Pass a google.maps.places.Place object to <PlaceOverview place={college} />.
3. The component internally calls place.fetchFields().
4. The Maps JS API throws a 429 (RESOURCE_EXHAUSTED) error.

Observed Behavior:
Instead of gracefully failing or displaying an error state, the component enters a synchronous "death loop." It continuously calls fetchFields() hundreds of times per second, flooding the Maps API with micro-requests and locking up the browser thread.

The sequence of events goes like this:

1. Select a college: The component fires fetchFields() for the first time. (Request 1 = Success!)
2. The Render Glitch: The component finishes rendering the data. But, because of the Lit bug (see Lit console warnings below), the component immediately triggers a brand new render cycle.
3. The Silent Loop: The component re-renders and fires fetchFields() again. (Request 2 = Success!). It glitches again, re-renders, and fires Request 3, 4, 5... all the way to 10.
4. The Crash: On the 11th render loop (which is happening a fraction of a second after the selection is made), the Google Maps API steps in, realizes you've hit your strict 10 QPM quota, and throws the 429 Too Many Requests error.

Lit console warnings:

• installHook.js:1 Element gmpx-place-data-provider scheduled an update (generally because a property was set) after an update completed, causing a new update to be scheduled. This is inefficient and should be avoided unless the next update can only be scheduled as a side effect of the previous update. See https://lit.dev/msg/change-in-update for more information.
• installHook.js:1 Element gmpx-place-photo-gallery scheduled an update (generally because a property was set) after an update completed, causing a new update to be scheduled. This is inefficient and should be avoided unless the next update can only be scheduled as a side effect of the previous update. See https://lit.dev/msg/change-in-update for more information.

Root Cause Hypothesis:
The issue appears to be inside the component's Lit lifecycle logic. When fetchFields() throws the 429 error, the internal updatePlace method catches it but fails to set a "resolved" or "failed" flag on the component's state. Because the component still believes it is missing required data, it triggers this.requestUpdate(). The updated() lifecycle hook fires, sees the data is still missing, and immediately calls updatePlace() again, creating an infinite loop.

Relevant Stack Trace:

2index-CXBbSg5r.js:758 MapsRequestError: PLACES_GET_PLACE: RESOURCE_EXHAUSTED: Error fetching fields: Quota exceeded...
    at async oo.updatePlace (index-CXBbSg5r.js:174:2758)
    at async oo.updated (index-CXBbSg5r.js:174:2166)
_$AE @ index-CXBbSg5r.js:13
performUpdate @ index-CXBbSg5r.js:13
scheduleUpdate @ index-CXBbSg5r.js:13
_$EP @ index-CXBbSg5r.js:13
await in _$EP
requestUpdate @ index-CXBbSg5r.js:13
set @ index-CXBbSg5r.js:13

This bug is not related to the React integration, and could conceivably happen in a vanilla ESC integration as well. The stack trace shows that the loop is completely contained inside index-CXBbSg5r.js (which is the minified bundle for the Lit Web Components). This is confirmation that the component is getting stuck in its own internal updated() lifecycle hook.

Suggested Fix:
Ensure that API rejections in updatePlace update the internal component state (e.g., setting an internal _fetchFailed = true flag) to prevent the updated() hook from infinitely retrying the network request.