fix(files_external): validate FTP and SFTP ports as TCP port numbers

[bahman026]

Follow-up to #63161, addressing the review suggestion there to validate that the port is an integer within the valid TCP range.

Summary

#63161 made FTP::__construct() fall back to the default port unless the configured value is numeric, mirroring the SFTP guard from #58350:

$parsedPort = $parameters['port'] ?? null;
$this->port = is_numeric($parsedPort) ? (int)$parsedPort : 21;

That fixes the empty-string crash, but is_numeric() still accepts values that are not usable TCP ports, and the cast then silently turns them into something else:

configured port	is_numeric() result	comment
"21.5"	21	truncated, no longer the configured value
"1e3"	1000	exponential notation accepted
"0"	0	not a valid port
"-2121"	-2121	not a valid port
"65536"	65536	above the maximum

The port field of an external storage holds whatever the administrator typed, so all of these are reachable through the UI. FTP and SFTP are the only backends that read ['port'].

Fix

Add OCA\Files_External\Lib\PortHelper::parsePort(), which returns the given fallback unless the value is an integer, or a digit-only string, within 1-65535:

$this->port = PortHelper::parsePort($parameters['port'] ?? null, self::DEFAULT_PORT);

Both backends use it, and the hardcoded 21 / 22 defaults are replaced with a DEFAULT_PORT class constant.

For SFTP the port can also be part of the host field (somehost:2222). That value now goes through the same validation, and remains the fallback when the port field itself is empty or invalid, so somehost:2222 with an empty port still connects to 2222.

Valid configurations are unaffected: an integer, or a numeric string such as "2121", resolves exactly as before.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Documentation (manuals or wiki) has been updated or is not required