Fix implicit globals and remove dead code in core/js

[limad]

Summary

Three pre-existing minor bugs in core/js/ found while auditing the codebase. Each is a one-line change that does not modify the surrounding declaration style (still using var to match the existing code).

Changes

• core/js/core.js — for (i in _replace) was leaking i as an implicit global on window. Now declared with var i.
• core/js/view.class.js (toHtml pre_success) — result = jeedom.view.handleViewAjax(...) was leaking result as implicit global. Now declared with var result.
• core/js/view.class.js (handleViewAjax graph zone loop) — option = configuration.replace(...) was leaking option as implicit global. Now declared with var option.
• core/js/private.class.js — var param = null; declared but never read. Removed (dead code).

Found via ESLint static analysis. Net diff: +3 / -4 lines across 3 files.

Why this matters

Implicit globals via assignment without declaration silently pollute window and can collide with other scripts. They also break under "use strict" mode (which is already declared in some Jeedom files like desktop/js/log.js).

Test plan

• Load a view page that calls jeedom.view.toHtml — verify rendering unchanged
• Load a view containing a graph zone — verify graph data attributes correctly populated
• Trigger any code path calling jeedomUtils.getTemplateFileContent with the _replace parameter — verify replacements still work

This PR is the first in a series (see #3297 discussion) splitting the previously-too-large optimization PR into focused changes.

[limad]

For context, while waiting for these PRs to be reviewed and merged,
I have additional work ready locally that I'd like to flag now (rather
than open silently and add to the queue):
Pending — JS bug fixes in desktop/js/ (~30 bugs documented)
While auditing desktop/js/ for the ongoing migration, I found ~30
pre-existing runtime bugs (typos like checkd / .values /
data-sixe_x, getElementById called with composed CSS selectors,
operator-precedence mistakes like !val === undefined, an array ==
in the scenario undo stack, missing try/catch around JSON.parse on
user-uploaded files and localStorage, an inverted search filter in
replace.js, etc.). All exist on develop independently of any
var/let work. Documented locally; happy to file as a GitHub issue
or split into a few small PRs grouped by theme — whichever you prefer.
Pending — var → const/let migration in desktop/js/
Same approach as #3300–#3303 but for the remaining 33 files in
desktop/js/. ESLint validates 0 errors, browser-tested clean on the
critical pages (dashboard, history, scenario, plugin, admin, mass
edit, etc.). Would split into 4 PRs by functional domain.
Strategy I'm following
I'll wait for some signal on the 6 currently-open PRs (A–F: #3298–
#3303) before opening anything else, so as not to overload the queue.
Happy to:

• close anything that doesn't fit the project's direction,
• restructure if a different split would help,
• file the bug list as an issue first so maintainers can prioritize,
• pause entirely and let upstream cherry-pick what's useful.
  Just let me know what works best for you.

[Salvialf]

Hi @limad,

It looks like the changes from this PR have already been covered by the other PRs that were merged afterwards, and the files involved have significantly evolved since then.

Given the current conflicts and the fact that the fixes seem to be already integrated elsewhere, this PR can probably be closed.
Can you confirm on your side?

[limad]

Confirmed — just checked against upstream develop: all three fixes (implicit i in core.js, dead var param in private.class.js, implicit result/option in view.class.js) are already integrated. Closing.