[MyvTsv]

• I have performed a self-review of my code.
• I have added tests (when available) that prove my fix is effective or that my feature works.
• I have updated the CHANGELOG with a short functional description of the fix or new feature.
• This change requires a documentation update.

Description

Reduces the Centreon API calls and the SQL cost of the plugin, mainly on the Computer list with the "Centreon Host Status" column.

• Status column: each row now calls only the host resources endpoint instead of the full host detail (host, resources, services, downtimes), and the status is cached for the request.
• Centreon login and plugin configuration kept in memory for the request: one login per page instead of one per API use; the cache is cleared when the configuration is saved; the settings diagnostic still always logs in.
• New index on glpi_plugin_centreon_hosts.centreon_id: the access check no longer scans the whole table.
• Unused COUNT removed from the tab label.
• AJAX endpoints release the session lock (Session::writeClose()) after the right checks, so a slow Centreon no longer blocks the user's other requests.
• The status shown in search results is now HTML-escaped (it comes from the Centreon API).

Schema change: the update adds the centreon_id index and now runs executeMigration(), which also applies the changeField() calls added in #60 and never executed until now (centreon_id becomes unsigned on installs older than 1.0.3).

Benchmark

GLPI 11.0.13, 52 000 computers, 50 000 Centreon mappings, Centreon API mocked at 50 ms per call (a real Centreon is usually slower, so the gains on API calls are a lower bound).

Scenario	SQL before	SQL after	Centreon calls before	Centreon calls after	Time before	Time after
S0 Home page (SQL per HTTP request)	46	44	0	0	1 112 ms	1 109 ms
S1 Computer form	160	159	0	0	289 ms	254 ms
S2 Centreon tab (tab server time)	135	134	5	5	300 ms	295 ms
S4 Computer list, 20 rows with the status column (page server time)	194	175	100	21	5 564 ms	1 257 ms
S5 Timeline (hostTimeline.php server time)	162	161	7	7	140 ms	138 ms

On S4, rows examined go from 1 054 557 to 54 520 (54 432 without the plugin) and SQL time from 154 ms to 23 ms; the page displays in 1.4 s instead of 5.7 s.
S4 still makes one Centreon call per displayed row: the remaining ~1.1 s grows with the page size and the Centreon latency; fetching all statuses in one call would be a separate change.
The other pages move within their measurement noise: they keep their Centreon calls, since the login is reused within a request only.