Refactor win detection to use a configurable winningValue

[mmiermans]

Replaces the hardcoded 2048 magic number in win detection with a single winningValue field on the GameManager, and rewrites hasWon() to reuse getMaxTile() instead of the previous loop that always returned false. Makes it trivial to support alternate win thresholds (e.g. 1024 / 4096) later.

[github-actions]

🤖 Claude has reviewed this PR — expand after forming your own opinion

Code Quality

Bug: off-by-one in move() win detection

move() uses > but hasWon() uses >=, making them inconsistent. With winningValue = 2048, the in-game check now requires a 4096 tile to trigger a win — the original code used === 2048.

The fix on line 356 should be:

      if (merged.value >= self.winningValue) self.won = true;

This also means hasWon() (called during setup() to restore state from a saved game) would correctly detect a 2048 win, but playing the game live would not — a subtle and hard-to-catch divergence.

Good fix on hasWon()

The old hasWon() was silently broken: the return true inside eachCell's callback returned from the callback function, not from hasWon() itself, so it always returned false. Rewriting it to delegate to getMaxTile() fixes that bug and is a nice DRY improvement.

Testing

No tests exist for this logic. Given that this PR fixes one latent bug (hasWon always returning false) and introduces one new bug (> vs >=), even a minimal test for the win-detection threshold would add confidence.

Security / Performance / Documentation

No concerns. The comment on winningValue is fine for a magic-number extraction.