### [FIX] website: fix GMaps deprecation console warning for s_google_map

Google deprecated the synchronous script loader for initializing the
Maps JS API. This caused browser console warnings.

The fix adopts Google's official `importLibrary()` bootstrap pattern,
which loads map libraries (places, maps, marker) lazily on demand rather
than all at once.The version is updated to `v=weekly`, which Google
recommends as it receives updates weekly versus quarterly for version
numbers(`v=number`).

Steps to reproduce:
1. Add the `s_google_map` snippet(not the`s_map`, enable debug mode)
2. Open the browser console and observe the deprecation warning


### [IMP] website: warn user to reload after GMaps config changes

Switching from the legacy Google Maps APIs to the new APIs requires
enabling additional services in Google Cloud. Existing maps using the
legacy API continue to work, but when an admin edits a map without a
proper configuration, the `GoogleMapAPIKeyDialog` dialog opens.

Google Maps configuration changes (API key update or enabling services)
do not take effect during the current editor session because the Maps
JavaScript API is loaded at page initialization.

Before this commit, such misconfigurations (disabled services or invalid
API keys) only triggered a dialog showing a generic Google Maps error.

After this commit, a notification informs the user that the page must be
reloaded for configuration changes to take effect.

The setup instructions are also updated to reference the
"Places API (NEW)" service.


### [IMP] website: replace deprecated Places API calls in GPS picker

The GPS picker relied on `PlacesService.nearbySearch` and `getDetails`,
which are part of the deprecated Places API. The new places API replaces
these with `Place.searchNearby` and `fetchFields`.

Error handling is consolidated into a single try/catch since the new
Places API throws on failure rather than returning a status code,
removing the need for `PlacesServiceStatus` checks.


### [IMP] website, *: replace deprecated Google Autocomplete
*: website_form_project

google.maps.places.Autocomplete is deprecated in the new Places API.
The replacement (`AutocompleteSuggestion.fetchAutocompleteSuggestions`)
does not fire DOM events, making it incompatible with the old
event-listener pattern used in GPSPicker.

A new Owl component (`PlacesAutoComplete`) is introduced to wrap the new
API, built on top of the existing `AutoCompleteWithPages`.


References:
https://developers.google.com/maps/documentation/javascript/load-maps-js-api
https://developers.google.com/maps/documentation/javascript/advanced-markers/migration
https://developers.google.com/maps/documentation/javascript/legacy/places-migration-overview

task-[4441041](https://www.odoo.com/odoo/project/974/tasks/4441041)

## Description

When validating an invoiced order in PoS Restaurant, an intermittent `undefined: Backend Invoice` error can occur if the user validates the order before the draft synchronization has completed.

This issue is difficult to reproduce consistently because it depends on network latency and the timing of user interactions.

### Steps to Reproduce

1. Open a PoS Restaurant session.
2. Add products to an order.
3. Click **Order** to start synchronizing the draft order.
4. Immediately click **Payment**.
5. Enable **Invoice** (select a customer if needed).
6. Click **Validate** before the draft synchronization finishes.
7. Under slow or unstable network conditions, the payment validation may fail with:

```
undefined: Backend Invoice
```

## Root Cause

During payment validation, `_finalizeValidation()` calls `push_single_order()` to synchronize the current order before creating the invoice.

In PoS Restaurant, `sendDraftToServer()` synchronizes draft orders asynchronously without acquiring `pushOrderMutex`, while `push_single_order()` performs synchronization while holding the mutex. Although both methods share the `syncingOrders` set, they are not synchronized through the same locking mechanism, allowing them to race.

The race happens as follows:

1. `sendDraftToServer()` starts synchronizing the draft order and adds its ID to `syncingOrders`.
2. Before it finishes, the user clicks **Validate**.
3. `_finalizeValidation()` calls `push_single_order()`, which invokes `_save_to_server()`.
4. Since the order is already in `syncingOrders`, `_save_to_server()` skips it and returns an empty array (`[]`).
5. The existing code only checks `!syncOrderResult`. Since an empty array is truthy in JavaScript, execution continues.
6. `_finalizeValidation()` then accesses `syncOrderResult[0]?.account_move`, where `syncOrderResult[0]` is `undefined`, resulting in the `undefined: Backend Invoice` error.

## Fix

Check that the synchronization result is both defined **and non-empty** before accessing its first element.

### Before

```javascript
if (!syncOrderResult) {
    return;
}
```

### After

```javascript
if (!syncOrderResult || !syncOrderResult.length) {
    return;
}
```

If `push_single_order()` returns an empty array, `_finalizeValidation()` exits early instead of attempting to access `syncOrderResult[0]`, preventing the exception.

This patch does **not** remove the underlying race condition; it simply handles the empty synchronization result safely.

## Notes

* This issue only affects **17.0**, where synchronization relies on `createFromUi()`.
* In **18.0**, the synchronization flow was redesigned around `syncFromUi()` and local model updates, so this specific race condition no longer occurs.

## Reproduction Videos

The issue is timing-dependent and requires slow network conditions together with rapid user interactions. After multiple attempts, it was successfully reproduced several times on Runbot.

1. [Reproduction Attempt 1](https://drive.google.com/file/d/1-KmaTiCErwv_OsWxYdmCvRUSI9oY3FOF/view?usp=sharing)
2. [Reproduction Attempt 2](https://drive.google.com/file/d/1MSG57nhZXfrAv1wuEkRbsmLstW5Hk9jg/view?usp=sharing)
3. [Reproduction Attempt 3](https://drive.google.com/file/d/1fXdyfNKUgJLTrrDZTi_FXuCmupBL3x-f/view?usp=sharing)

opw-6367134

### Issue before this commit:
When importing an electronic invoice from SDI that is failing with an exception, the resulting account.move record was saved in the "Miscellaneous Operations" journal instead of the correct one (Vendor Bills), even though the move_type itself was correct.

### Steps to reproduce the issue:
Pre steps: you need to have access to https://iap-services-test.odoo.com/odoo
1. Download Accounting and l10n_it
2. Go to Settings > Companies and set the VAT of IT company the same as the one in the xml
3. Go to Settings > Italian Electronic Invoicing and select Test
4. Go into the code and insert an Exception inside the function _l10n_it_edi_import_invoice after self.move_type = move_type (or create any type of exception from the user interface)
5. Go to IAP service into IT EDI app and see that your company is there as user
6. Click into the record > receive move button > upload your xml > create
7. Go to your DB > Scheduled Actions > filter with IT > IT EDI: Receive invoices from the SdI > Run Manually
8. Go to Journal entries, remove the filter and find your imported bill
9. You can see it was inserted into the Miscellaneous Operations Journal instead of a Vendor Bill Journal

### Cause of the issue:
The move is created inside a savepoint context manager, designed so that even if parsing fails, an empty move with the attachment still remains. The problem is that if the exception is raised, the savepoint rollback undoes everything that follows, but the journal was already determined before the correct move_type was known, leaving the move in the wrong default journal.

### Reason to introduce the fix:
The fix is needed to ensure that, regardless of where parsing fails, the move's journal is correctly set even if an exception occurs so that it is possible to find the move in the correct section even if not imported correctly.

opw-6397712

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr