fix sftp via proxy recording mode

[fspmarshall]

Teleport was incorrectly generating an AccessDenied error when users who were authorized to copy files attempted to do so via a proxy that was configured for proxy recording mode.

Bug was originally introduced as part of the permission-handling refactor in #54081. That PR split up permissions into separate pre-calculated "permit" objects instead of passing around a bare access checker object. Part of that work necessitated separating out "access" permissions from "proxying" permissions. SSH file copying permissions needed to be evaluated as part of proxy recording mode, but that PR incorrectly omitted ssh file copying from the proxying permit.

Long-term, we would like to prevent this kind of oversight more robustly by moving away from using the proxyingPermit in recording mode, in favor of either a dedicated permit type for recordings, or reusing the SSHAccessPermit type and hard-coding certain inapplicable permissions to safe defaults. It is confusing from a code-organization perspective to have standard proxying and recording proxying use the same permit type, and can be actively misleading since the proxy recording mode tends to function much more like a local access than like an invocation of the actual proxy subsystem.

Fixes #58847

changelog: Fixed an issue where SSH file copying attempts would be spuriously denied in proxy recording mode

[rosstimothy]

I've tested this with the reproduction steps stated in the issue before and after this change and can confirm that upload and downloading of files works via the UI and the command line in proxy recording and node recording modes.

[backport-bot-workflows]

@fspmarshall See the table below for backport results.

Branch	Result
branch/v18	Create PR