[ADITYASINGH1206]

Closes #472.

What problem does this PR solve?

In io.kestra.plugin.scripts.python.internals.PythonEnvironmentManager, when inferring the Python version from a container image tag, looksLikePythonVersion() parsed the tag prefix with Integer.parseInt(version.split("\\.")[0]) and checked major >= 2.

When custom Docker images use numeric timestamps or build dates (e.g., python:20261021113000 or python:20241021), this resulted in:

1. NumberFormatException when numeric tags exceed Integer.MAX_VALUE (e.g., 14-digit timestamps), aborting task execution during environment setup.
2. Falsely accepting build dates (e.g., 20241021 >= 2) as valid Python versions, causing package resolution and cache key generation to fail downstream.

What changes are made in this PR?

1. PythonEnvironmentManager.java:
   • Added null/empty guard returning false.
   • Wrapped Integer.parseInt() in a try-catch block catching NumberFormatException and returning false.
   • Validated that the major version is within valid Python major versions (major >= 2 && major <= 9), rejecting 4-digit years, 8-digit dates, and build timestamps while accepting Python 2 and 3.
2. PythonVersionParserTest.java:
   • Added unit test cases for numeric timestamps (20261021113000), build dates (20241021), build years (2024.1), and invalid/null inputs.

[Malaydewangan09]

Thanks, the fix is right: the try/catch stops timestamp tags from crashing the task, and the <= 9 bound rejects build dates while still accepting future Python majors. I removed the null/empty guard because the only caller passes a regex match of digits through Optional.filter, so it can't be reached, and dropped its test. I also updated the Javadoc.

I pushed these tweaks.