When a customer adds an empty internal note and tries to order the product,
a traceback will appear.

Steps to reproduce the error:
- Open PoS restaurant session
- Add any product > Order
- Add same product again > Add an empty internal note
- Order

Traceback:
```
KeyError: (3, 'pou', '[]')
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/pos_restaurant_preparation_display/models/preparation_display_order.py", line 33, in process_order
    res = super().process_order(order_id, cancelled, note_history)
  File "home/odoo/src/enterprise/saas-17.2/pos_preparation_display/models/preparation_display_order.py", line 28, in process_order
    data = order._process_preparation_changes(cancelled, note_history)
  File "home/odoo/src/enterprise/saas-17.2/pos_preparation_display/models/pos_order.py", line 95, in _process_preparation_changes
    quantity_data[key_new]["display"] += old_quantity["display"]
```

https://github.com/odoo/enterprise/blob/4077a5e39fba7197d32d5db05171ad9c8f98c392/pos_preparation_display/models/pos_order.py#L95
Here when customer adds an empty internal note, ```quantity_data``` will become empty,
So, it will lead to the above traceback.

sentry-5494183916

**Current behavior:**
There are several related bugs when operating in a multi-company
environment with the barcode app:

*Given:* we have three companies in the selector (A, B, C) where
company A is the first/default/primary of the three.

***Case 1: (CompanyB and CompanyC are checked, either can be focused)***
1) Scanning the barcode for CompanyC's manufacturing operation and
then, within the barcode view, scanning a product which belongs
exclusively to CompanyB will make it impossible to use the back
button (despite the product correctly not being added as a line
in the operation).

2) Repeating the setup with a different operation type (e.g.,
receipt) *will* add the product to the picking but it will not
be possible to validate/take out of draft from either the
barcode app nor from the backend.


***Case 2: (only CompanyC checked and focused)***
1) Scanning the barcode for CompanyC's manufacturing operation type
will open the barcode operation view for CompanyA's manufacture
operation. Products available to CompanyC can be added. Trying
to validate the order will cause an access error, however the MO
is still created in the backend.

2) Scanning the barcode for either CompanyB or CompanyA's
non-manufacturing operations will show an access error dialog,
but an (empty) transfer will still be created in the backend for
the respective company.

---

**Expected behavior:**
In case 1, scanning a product which is not available to the
current company should not trap the user in the barcode
operation view. It should also not add these inaccessible
products to a picking thereby making them unable to be
validated.

In case 2, we should respect the company defined on a
manufacturing operation type which corresponds to a scanned
barcode. Additionally, it should not be possible to create empty
transfers for companies which are not currently checked/active.

---

**Cause of the issue:**
Problem 1: production records (unlike pickings) cannot be
created until a product is added in the barcode view. Because of
this different flow, they are created with less context than
other operation types and there was no mechanism by which their
`company_id` could be inferred.

This caused them to use the default value as defined in the
`MrpProduction` model (`self.env.company`)- which is problematic
in the barcode app, as this field does not actually correspond
to the focused/active company.

Problem 2: when scanning a picking type from the main menu of
the barcode app, the company of the picking type was not getting
respected which would cause a new picking record to be created
even when the current user/environment did not have permission.

---

**Fix:**
1. Create production records using a default `company_id` value
informed by their `picking_type_id` rather than the environment

2. In the main_menu barcode scan route, use the current user's
allowed company ids (from their cookies) to restrict searchable
records

3. When scanning products in a barcode operation view, use the
company_id of the opened operation type to restrict the domain
of searchable records.

opw-3999622