fix: don't raise the weight in double progression before the top of the range

[bluzername]

Fixes #278.

What was wrong

Double progression should only add weight when every set reaches the top of
the rep range. The code checked last.ok, but that only means the session
matched whatever reps were recorded as its own target for that session -
not that it reached the top of the range. A fresh exercise's first session
gets its target seeded at the bottom of the range (8 of an 8-12 range,
say). Doing exactly 8 reps in every set matched that target, so it read as
a full hit and the weight went up right away, before the range was ever
climbed. This matches the report in #278 exactly: 3 sets of 8 (the bottom
of an 8-12 range) triggered the weight step on the very next session.

The fix

In the double policy branch of nextPrescription, only treat a session
as earning more weight when it also reached the top of the range
(last.low >= top), not just when it matched its own recorded target.

Test

Added a test in frontend/src/lib/progression.test.js:
"does not raise the weight for a session that only matched its own
recorded target, short of the top of the range (issue #278)" - builds a
history where the recorded target is the bottom of the range (8) and all
sets hit exactly 8, and asserts the next prescription is not up.

I confirmed it fails on unmodified code (expected 'up' not to be 'up')
and passes after the fix.

Verification

• cd frontend && npx vitest run src/lib/progression.test.js - 97/97 pass
  (was 96/97 with the new test added before the fix, RED confirmed by
  temporarily reverting the fix).
• cd frontend && npx vitest run - full suite, 1573 tests, all pass (a
  few files hit a vitest worker-pool timeout under sandboxed CI-like
  parallelism and pass cleanly when run alone - not related to this
  change).

No new dependency, one file of production code touched
(frontend/src/lib/progression.js), plus its test file.

This account (bluzername) is not a collaborator on this repo, so I can't
merge - opening this for a maintainer to review.

🤖 Generated with Claude Code

[tdsnxsuplewski-mateusz]

This fixes the immediate weight-increase symptom. I ran into the same
root cause while looking at it and found it goes a bit deeper: entry.target.reps (what
readSession() grades every session against) still stores the climbing aim rather than the
range's top, since session-start.js isn't touched here. That keeps stallCount() (deload
timing) and epleyDeload() (post-deload weight sizing) reading the understated value.

Opened PR#301 which fixes the stored value at the source instead, so all three
call sites are consistent. Not trying to step on this — happy either way, just flagging so
it's an informed call on which to merge.

[Diego-Sanchez2000]

Thanks for the quick PR and fix. I really appreciate you taking the time to sort this out.

[DuarteSantos8]

Thanks @bluzername, merged as it was, and it fixes #278.

One correction to the description, for anyone reading this later: a genuine first double-progression session is stamped at the top of the range, so 3×8 there already holds. The path #278 hit is a bottom stamped after an "up", for example history at 8 reps under linear followed by a switch to double 8–12. Your last.low >= top guard stops that path, and I corrected the matching code comment. Could you edit the description?

@tdsnxsuplewski-mateusz's #301 goes after the same root cause for the stall count and the deload. I've answered there.

Released in v1.3.9: https://github.com/DuarteSantos8/openGym/releases/tag/v1.3.9