fix: reject non-positive block count requests

[tolga-tom-nook]

Summary

• reject GET /blocks/last/{n} requests when n is zero, negative, or non-numeric
• apply the same validation to GET /blocks/data/last/{n}
• keep the existing upper cap of 2016 for valid large counts
• replace assertion-based parsing with explicit validation and add isolated unit coverage for both handlers

Why

Before this change, invalid n values were parsed directly with int(n). Non-numeric values fell through to the generic internal-error response, while zero/negative values could be sent to the model layer even though these endpoints are documented as last-N block queries.

Validation

• python3 -m py_compile api/views/blocks.py test/pytest/blocks_data/test_block_count_validation_unit.py
• python3 -m pytest -q --confcutdir=test/pytest/blocks_data test/pytest/blocks_data/test_block_count_validation_unit.py → 3 passed
• synthetic unit coverage verifies 0, -1, and abc return HTTP 400 / PARAMETER_ERROR for both affected handlers without calling model functions, and valid counts still call the model with the 2016 cap preserved

Bounty context: Bitgesell improvement program / PR bounty hunt (#39, #81).

---

Executor refresh (2026-06-18T03:18:49Z)

Revalidated payout readiness for the Bitgesell PR-bounty queue without changing code:

• python3 -m py_compile api/views/blocks.py test/pytest/blocks_data/test_block_count_validation_unit.py
• python3 -m pytest -q --confcutdir=test/pytest/blocks_data test/pytest/blocks_data/test_block_count_validation_unit.py → 3 passed
• git diff --check origin/master...HEAD
• git rev-list --left-right --count origin/master...HEAD → 0 2

No maintainer requested-changes review or failing local proof found in the recheck.

[MyTH-zyxeon]

Maintainer-facing review assist for the #81 / #39 bounty queue:

This is a good bug-fix direction: both GET /blocks/last/{n} and GET /blocks/data/last/{n} should reject 0, negative, and non-numeric counts before reaching the model layer, while preserving the existing 2016 upper cap for valid large requests.

Acceptance checks I would use before merge:

• Consider replacing assert n > 0 with an explicit if n <= 0: branch. assert can be disabled with Python optimization flags, and input validation should not depend on assertion execution.
• Narrow the inner except to the expected parse/validation failures instead of a bare except, so unrelated errors are not accidentally converted into PARAMETER_ERROR.
• Keep the same behavior for both handlers and preserve the existing cap: valid n > 2016 should still become 2016, while 0, -1, and abc should return HTTP 400 / PARAMETER_ERROR without calling the model layer.
• If possible, add a small regression test around both route handlers using the existing test style; the synthetic handler check described in the PR body is good evidence, but a checked-in test will protect the endpoint contract.
• For bounty accounting, tie this explicitly back to BGL (Bitgesell) Bounty/Improvement Program ($50000 budget) bitgesell#81 / #39 after approval so submitter and maintainers agree on the review lane.

No payment action or claim from me here; just a focused review pass to help maintainers evaluate the PR.