Make the CI ESLint step actually gate (run lint without --fix)

[Valyrian-Code]

Problem

The test.yml workflow runs the lint step as npm run lint, and the lint script is:

"lint": "eslint js --ext .jsx,.js --fix"

Because --fix repairs every auto-fixable problem in the runner and then exits 0, any auto-fixable violation passes CI green — the lint step never fails on them. Over time 102 such violations (indentation, plus one react/wrap-multilines) accumulated in committed code while CI stayed green.

Reproduce on current master:

cd geonode_mapstore_client/client && npm install
npx eslint js --ext .jsx,.js   # 102 errors, all "potentially fixable with the --fix option"
npm run lint                   # exits 0 — it silently fixes them in the runner

Fix

Two commits, kept separate:

1. Clear the 102 existing violations with a one-time eslint --fix. The change is whitespace/indentation only, plus one inert react/wrap-multilines paren wrap — no behavior change (git diff -w shows only that single paren wrap).
2. Add a lint:ci script without --fix and point test.yml at it, so the lint step gates again. The local lint script keeps --fix for developer convenience.

Verification

• npm run lint:ci exits 0 after the fixes.
• Full unit suite still passes — 339 tests completed, 0 failures.
• Node 20, matching CI.

Question for maintainers

Was running --fix in CI intentional? If you'd prefer flipping the convention so lint is the check and a new lint:fix does the fixing, I'm happy to adjust — just say which you'd rather have.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[gemini-code-assist]

Code Review

This pull request primarily introduces formatting and indentation updates across several React components and utility files, alongside adding a new lint:ci script to package.json. A potential runtime TypeError was identified in UploadUtils.js where currentSupportedType.required_ext is accessed without a fallback check. A code suggestion has been provided to safely handle this scenario and prevent potential crashes.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[Valyrian-Code]

Thanks — good catch. This PR only reindents those lines (it's a CI lint-gate change), so the missing required_ext guard is pre-existing behavior. To keep this PR single-concern I've addressed it separately in #2561, which adds the || [] guards (matching getSupportedTypeExt) plus a regression test that reproduces the TypeError for a supported type declaring only optional_ext.