feature/SOF-7990 fix: PointsGridDataProvider derives gridMetricValue

[VsevolodX]

Problem

Clone a job whose k-grid was set explicitly in a notebook, then try to change the k-grid on the clone: nothing happens. The value is stuck, the metric reads -1, and no error is shown.

PointsGridDataProvider(dimensions=SCF_KGRID, isEdited=True) — the exact call total_energy.ipynb makes — never supplies gridMetricValue. It defaults to the DEFAULT_KPPRA sentinel (-1) and gets persisted as if it were a deliberate, edited value:

>>> PointsGridDataProvider(dimensions=[4,4,4], isEdited=True).get_context_item_data()
{'name': 'kgrid', 'isEdited': True, 'data': {..., 'gridMetricValue': -1}, 'extraData': {}}

That is wrong regardless of downstream effect: a sentinel meaning "nothing was ever computed" gets marked isEdited: True and persisted as if it were the user's deliberate choice, and nothing downstream ever recomputes it (checked both sides — Python's _get_effective_data and JS's this.data?.gridMetricValue || this.defaultMetric.value, which treats -1 as truthy and passes it straight through).

Correction, added after initially opening this PR: I first claimed the observed "locked, can't edit" symptom was caused by the k-grid form's schema requiring gridMetricValue >= 1 for KPPRA, with RJSF re-validating the full form state on every edit and silently rejecting it. That claim was wrong. I verified it against a hand-copied version of the schema, not the actual compiled one; running it against the real KGridFormDataManager class shows the minimum: 1 constraint never actually reaches the schema RJSF validates against — getPatchedSchemaById's dot-notation merge (applyPatchWithDotNotation in @mat3ra/esse) can't create the missing intermediate dependencies key that the base ESSE schema doesn't have, so the whole patch silently no-ops. Confirmed: gridMetricValue: -1 validates true against the real schema, same as 64. So this PR does not have proof of why editing locks in the UI — only that the persisted -1 is wrong on its own terms. The dependencies patch being dead code is a separate, likely-unrelated bug worth its own look.

Fix

PointsGridDataProvider now derives gridMetricValue from dimensions (× an optional n_atoms, default 1) whenever dimensions are given explicitly but the metric is not — mirroring PointsGridFormDataProvider.setData() in JS, which already does exactly this when a user sets dimensions manually in the UI. An explicitly passed gridMetricValue is still respected; the untouched default path (no dimensions, no metric at all) is unaffected and correctly keeps the -1 sentinel, since there's nothing to derive a value from.

>>> PointsGridDataProvider(dimensions=[4,4,4], isEdited=True).get_context_item_data()
{'data': {..., 'gridMetricValue': 64}, ...}   # was -1

Test plan

• pytest — 85 passed (baseline 81 + 4 new)
• New tests cover: derives from dimensions (64 for [4,4,4], n_atoms=1); respects an explicit override; derives correctly with a real n_atoms; untouched default path keeps the sentinel
• convergence_mixin.py's separate call pattern (PointsGridDataProvider(data=kgrid_data)) verified unaffected — it never sets the dimensions field, so the new derivation logic doesn't fire
• Ruff clean (pre-existing files were already clean; confirmed via git stash)
• CI green: https://github.com/mat3ra/wode/actions/runs/31282112756

Not fixed here

• Numeric parity with JS's nAtoms requires the caller to actually pass a real atom count — n_atoms defaults to 1 since this provider has no material context of its own. Left as a follow-up in api-examples.
• Whatever actually causes the reported UI lock is still unidentified. The -1 persistence is fixed regardless because it's wrong on its own terms, but I have not located why editing a cloned job's k-grid was observed to silently fail. That likely requires checking @mat3ra/workflow-designer, which isn't checked out in this task.
• The dependencies patch in jsonSchemaPatchConfig being silently dropped (dead code — the preferGridMetric/KPPRA-vs-spacing branching never applies) is a separate bug, filed in log/findings.md.

[exabyte-io-bot]

2 blocker(s) to resolve before this merges, across 5 finding(s).

Batched findings

• nit tests/py/context/test_points_grid_data_provider.py:123 — (AGENTS.md 5.1) A couple of small nits, non-blocking: here and on line 132, let's spell out the math (e.g. 4 * 4 * 4 and 4 * 4 * 4 * 2) instead of hardcoding the magic numbers 64 and 128. It makes the test act as self-documenting proof of the logic. Also, in calculate_grid_metric, the units argument is completely unused — let's remove it if the base interface allows it. Happy to approve once those are in.

Generated from Timur Bazhirov's review corpus (12,340 of his own past comments). Severity follows AGENTS-code-review-tb.md; confidence is the model's own estimate.

[exabyte-io-bot]

(TB-NAME-1) Let's spell this out — n_atoms uses an abbreviation that violates our naming conventions. We should use number_of_atoms instead. (See AGENTS.md HARD RULE 4).

[exabyte-io-bot]

(TB-DOC-2) Let's add a docstring here explaining what this validator does and why it's triggered after initialization. All new methods need docstrings.

[exabyte-io-bot]

(AGENTS.md 1.2. OOP Guidelines & Antipatterns) Why is grid_metric_type typed as a str in the signature but compared to an enum GridMetricType.KPPRA here? Let's ensure the type hint matches the actual usage (e.g. GridMetricType or Union[str, GridMetricType]) to prevent type-checking failures or silent comparison bugs.

[exabyte-io-bot]

(TB-DRY-1) Let's avoid hardcoding the exact 3 indices here. Using math.prod(dimensions) * self.number_of_atoms (assuming n_atoms gets renamed per the other comment) makes this safer for 1D or 2D grids and a bit cleaner to read.