fix: return validation error instead of 500 for out-of-range task_ids

[mvanhorn]

Summary

Saving the "Create your own task pack" form with an out-of-range task id now shows an inline validation message instead of a 500. Ids like 999999999999999999 parse fine in Elixir's arbitrary-precision integers, pass changeset validation, and then blow up inside Repo.insert with a Postgrex "integer out of range" error; the form now rejects them at cast time.

Why this matters

Reported in #1646 with three independent reproductions (2024-01, 2024-03, and 2026-07-06 on commit 2acd190). Codebattle.TaskPackForm.cast_task_ids/2 already rescues String.to_integer/1 failures for non-numeric input, but numeric input beyond PostgreSQL's int4 range reached the database and surfaced as a 500. The same path existed for update.

Changes

• cast_task_ids/2 in apps/codebattle/lib/codebattle/forms/task_pack.ex validates every parsed id is a positive integer within int4 range (1..2_147_483_647) and adds a changeset error in the same user-facing style as the existing parse-error message. The existing non-numeric rescue is unchanged, and no controller changes were needed: create/2 and update/2 already re-render the form when the changeset carries errors.

Testing

Controller tests cover the non-numeric string case and the out-of-range integer case for both create and update, asserting the form re-renders with the validation message rather than raising.

Fixes #1646

[mvanhorn]

Looked into the failing build check: it's mix credo --strict flagging 5 readability issues in files this PR doesn't touch — user_show_view.ex:248 and public_event_controller.ex:29 exceed the 120-char limit, plus 3 consecutive-blank-line hits in the view files. All of them are present on master as it stands, so any PR will currently trip this check. Happy to send a separate small PR cleaning those up if that'd help.