Steps to reproduce:
1. Open a storable product with variants on the Product Page, in edit mode.
2. In the builder sidebar, select the specific variant (e.g. "Customizable Desk (White, Steel)").
3. Set its Ribbon to any value (e.g. "Sold out").

Before this pr:
 - The selection crashed with: TypeError: Cannot read properties of null (reading 'getAttribute') at SetRibbonAction.apply After this pr:
 - The ribbon is set/created/deleted normally on the variant, no crash.

`SetRibbonAction`, `CreateRibbonAction` and `deleteRibbon` looked up the selected variant via
`editingElement.querySelector('[data-oe-model="product.product"]')`. That marker never exists on the product page only `product.template` fields (`product.name`, ...) are rendered with `t-field`, never `product.product` fields, so the selector always returned null and the following `.getAttribute(...)` call crashed.


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

Forward-Port-Of: odoo/odoo#288466

Before this commit, the call view arranged its cards by rewriting CSS variables. Cards jumped to their new place instead of moving to it, and a rearrangement recreated their elements, so a video glitched and restarted from scratch on every layout change.

This commit fixes the issue by computing the rendering outside the component, around three concepts:

- the "stage" is the one area a call renders into, shared by the tile grid, the sidebar that reserves its room out of the grid's, and the inset overlaying the first tile;
- a "surface" is one entry of that stage, held by a stable identity rather than by its position, so a layout change moves it, media and all, instead of recreating it;
- a "profile" is the set of layout knobs a call resolves to, one per place it renders in: Discuss, meeting, chat window, PiP and phone.

Four modules carry them:

1. `call_profile.js` resolves the call into a `CallProfile`, the knobs everything else runs on: adding a profile is a new `CALL_PROFILE_TYPE` and a new case, never a branch elsewhere.
2. `stage/surface_manager.js` reconciles the desired surfaces with the live ones, so a video travels grid <-> sidebar <-> spotlight without being torn down.
3. `stage/layout_engine.js` turns the profile, the measured stage and the desired surfaces into rectangles. Deterministic and side-effect free.
4. `stage/geometry_renderer.js` applies those rectangles through the Web Animations API, outside the render loop, so surfaces move on the compositor instead of jumping.

This commit also makes these miscellaneous changes:

- the spotlight splits its stage between the recent speakers, kept 3s after they stop talking, instead of swapping on every sentence;
- cards are ordered by what the stage must not hide: presenters, then speakers in the order they took the floor, then self;
- the inset snaps to the nearest corner, stored as a corner rather than pixels, so it survives a resize;
- on a small screen the call bar folds everything but the microphone, the camera and their settings into one "More" menu;
- "Switch Camera" moves into the quick video settings;
- in a chat window, the fullscreen button no longer pulses to nudge the user into it when another participant turns their camera on.

task-4781315

Forward-Port-Of: odoo/odoo#282766

Before this commit, the OdooBot conversation showed "This is the start of your conversation" instead of the last message of OdooBot, and could not be marked as read.

Steps to reproduce:
- log in as a new internal user, so that the onboarding creates the OdooBot chat and posts its welcome message
- open the messaging menu, "Chats" tab
- the OdooBot conversation shows no message preview, and marking it as read leaves its unread counter at 1

This happened because the messaging menu excluded from its own fetch every channel already in the store, no matter how it got there. `init_messaging` adds the OdooBot chat without its last message: it only needs the channel itself, to auto-open the chat during onboarding. So the message was never loaded, while both the preview and `markAsRead` needed it client side.

This commit fixes the issue by no longer relying on the mere presence of the channel in the store: it is excluded only if its last message has been fetched too, either because the server sent it along the channel (new `lastMessageFetched` flag, set by the routes requesting the last messages of the channels they add to the store), or because the thread has been loaded, in which case its messages necessarily contain the last one.

(See the Odoobot notification's message)

<img width="396" height="630" alt="before-master" src="https://github.com/user-attachments/assets/c67ce8cf-a363-4fb6-94fa-2ada9ba08e4b" />

<img width="396" height="630" alt="after-fix" src="https://github.com/user-attachments/assets/bb74ee5a-3f5f-4b8a-bfd1-5662d7a52dca" />

Forward-Port-Of: odoo/odoo#287749