Fix: Accept additional correct solutions in L14.P2 damage check

[madison-nicole]

Please check if the PR fulfills these requirements:

• The commit message follows our guidelines.
• For bug fixes and features:
  • You tested the changes.

Related issue (if applicable): #1388

What kind of change does this PR introduce?

Bug fix: widens the static check for practice L14.P2 "Reducing damage at
higher levels" so it accepts more correct solutions.

Does this PR introduce a breaking change?

No. All previously accepted solutions still pass; the change only adds
alternatives to the existing GDExpr.any_of pattern in
TestReducingDamage.gd. No practice text or error messages were touched,
so there is no translation churn.

New feature or change

What is the current behavior?

The check "Multiplication Is Used To Reduce Damage Amount" only matches
amount *= 0.5 and amount = amount * 0.5 (operand order is already
flexible, so amount = 0.5 * amount also passes). Other solutions that
produce exactly the specified behavior, half damage above level 2, full
damage below, fail with "It looks like amount isn't reduced by a
percentage," even though the behavioral check passes.

What is the new behavior?

Two additional forms are accepted, both of which keep the practice's
intent of assigning the reduced value back to the parameter:

• amount -= amount * 0.5
• amount /= 2 (also matches 2.0, since literal matching uses Variant ==)

Out of scope, up to the maintainer

• Reducing at the subtraction site (health -= amount * 0.5 with an
  else branch which is the exact code from L14.P2 Reducing damage at higher levels: check rejects correct solutions that don't reassign amount #1388): accepting it would drop the
  assign-to-parameter requirement entirely, which is a lesson-design call
  for a practice about multiplication.
• amount = amount / 2: easy to add with GDExpr.bin_op(..., OP_DIVISION)
  if wanted.

[NathanLovato]

Did you really test the changes, or did you e.g. use an LLM to make the PR? Because the code changes do not address #1388, the provided code or variants of it will still fail the same test.

One more note. In general, for open source maintainers, LLM generated PR descriptions like this create more noise than they help. I would personally recommend when you're experienced and you know what you're doing to fill only relevant parts of the template or skip some of it. The template serves more as a mental checklist to ensure a minimum level of personal involvement in contributions. It's for real people to communicate.

[madison-nicole]

@NathanLovato Yes, I have manually tested the changes. I felt like the code changes address a subset of 1388, like expanding the test cases to include more correct solutions, but they do not address the exact issue I originally ran into when doing the tutorial, which I noted at the bottom of the PR description. You can read that here:

I would be happy to make that additional change if permitted on this PR or another but was unsure if you wanted to require variable assignment for the solution or not, so I left it noted at the bottom as a potential follow-up.

I have been working as a software engineer in the tech industry for several years, before LLMs were around. I used Claude Code to generate some testing scripts and run them and also fill out a boilerplate PR description, of which I manually read every word and edited most of in order to accurately reflect the situation. If there is a rule against using Claude Code for this repo at all, then I apologize as I must have missed it, but this is the workflow I have used in the industry for a couple years now since Claude Code's significant advancements.

Is there an issue with the actual code itself, or do you just want the subtraction-site pattern added?

[NathanLovato]

Thanks for your message, and sorry I misunderstood the PR as aiming to be a bug fix for the linked issue.

When I ask a question or say something, there's no extra implications. Thanks for confirming you tested the changes.

On the changes themselves:

• I'd like to remove the check for dividing by 2. I understand where it comes from, just as the app is for neophytes, I prefer to keep constraints that don't risk creating confusion. It's minor though.
• You can definitely go ahead and address L14.P2 Reducing damage at higher levels: check rejects correct solutions that don't reassign amount #1388, the tickets makes a lot of sense, the exercise definitely shouldn't require people to modify the input parameter.

If you're up for making the changes, you're more than welcome to do it in this PR. I really appreciate you taking the time to open the ticket, and also to follow up!