`TestForumInternals` assumed that only the base forum and the forum created by the test setup existed in the database.

This is not true when tests are run with demo data. In particular, `website_slides_forum` creates additional demo forums, causing `test_assert_initial_values` and the forum count assertions to fail even though the forum behavior itself is correct.

This commit avoids relying on the global number of existing forums and instead scope the initial-value assertions to the forums owned by the test itself.

For forum count tests, we use the count observed at the beginning of the test as a baseline and assert the expected deltas after creating or updating forums. This keeps the test focused on the behavior being tested while allowing unrelated forums to already exist.

This also avoids modifying, archiving, or explicitly filtering demo records, and does not introduce a dependency on modules such as `website_slides_forum`.

The tests therefore behave identically on databases both with and without demo data.

[error-241100
](https://runbot.odoo.com/odoo/error/241100)


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

Problem:
`_compute_electronic_product_code` built `tracking_number_list` by filtering out move lines without a lot_id/lot_name, but kept iterating over the full, unfiltered `move_line_ids`. As soon as a tracked product had an untracked move line mixed in with tracked ones (e.g. a manufacturing byproduct move line with no lot), the two lists fell out of sync: at best tracking numbers got assigned to the wrong move line, at worst `tracking_number_list[i]` went out of range and raised an IndexError.
Solution:
Exclude untracked move lines from `move_line_ids` before building `tracking_number_list`, so both stay the same length and index- aligned. Untracked lines get their own explicit "no tracking number" error instead of breaking the alignment for the rest.

Steps to reproduce:
Open runbot V19 -> go to moves history (Inventory) -> add `electronic_product_code` to list view using studio -> remove filter/select all records -> https://anotepad.com/notes/jwxyskc2

Forward-Port-Of: odoo/enterprise#128521
Forward-Port-Of: odoo/enterprise#123859

When a helpdesk team has its website form enabled, a dedicated qweb view is generated from the `ticket_submit_form` template. The arch was read in the language of the user creating or editing the team, so a team set up by an English user language produced an English form even when the website served another language.

Steps to reproduce
==================
1. Set a language other than English as the website default language.
2. While your user language is English, create a helpdesk team with the website form enabled.
3. Open the team form on the website.

=> The form is rendered in English instead of the website language.

Root cause
==========
`_ensure_submit_form_view` read the template arch without forcing a language, so it used the current user's language and stored only that value on the generated per-team view.

Fix
===
Read the template arch in the default language of the team's website, so the generated form matches the website language regardless of the user's own language.

opw-6303903

Forward-Port-Of: odoo/enterprise#129265
Forward-Port-Of: odoo/enterprise#121164