[Feature] 请求为crypt驱动添加超长文件名的支持

请确认以下事项

• 我已确认阅读并同意 AGPL-3.0 第15条 。
  本程序不提供任何明示或暗示的担保，使用风险由您自行承担。

• 我已确认阅读并同意 AGPL-3.0 第16条 。
  无论何种情况，版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。

• 我确认我的描述清晰，语法礼貌，能帮助开发者快速定位问题，并符合社区规则。

• 我已确认阅读了OpenList文档。

• 我已确认没有重复的问题或讨论。

• 我认为此问题必须由OpenList处理，而非第三方。

• 我已确认此功能尚未被实现。

• 我已确认此功能是合理的，且有普遍需求，并非我个人需要。

需求描述

1、在使用crypt驱动的加密文件名功能后，在最后需要转码为base64等编码保存，这样带来的一个结果是字符串长度会变长，发生超过网盘文件名长度限制的几率会大大升高。因此希望针对此情况，引入一个增强功能选项，解决长文件名（包括长文件夹名）的问题
2、原crypt驱动旨在100%与rclone相关功能的双向兼容，加入这个功能项后，经过“长文件名兼容”处理的部分文件，在rclone加密驱动下无法正常识别，需要在openlist的功能设置页面明确指出。
3、实在需要rclone读取的，可以由他把相应文件下载到本地等支持更长文件名的储存后端后，手动拼接文件名恢复，简单可逆，影响不是很大。

实现思路

1、基本思路是借鉴目前chunk驱动的文件名前缀方式，添加特定前缀譬如”part”，识别该文件名需要特殊处理。

需要处理的文件，把文件名按长度分成几个文件名序列，格式为：前缀识别码.文件识别码.序列.文件名补全部分。其中前缀识别码就是part，标识这是一个拆分文件名片段；文件识别码，可以从原文件名中提取前5位，如有冲突就提取到前10位，以此类推，用于标识同组的文件名片段；序列就是递增的数字序列，标识片段顺序；文件名补全部分就是最终用于拼接文件名的余下部分。

譬如文件名：ABCDE12345abcde，拆分成：part.ABCDE.0.12345和part.ABCDE.1.abcde
完整的文件名用文件识别码ABCDE和0序列的12345和1序列的abcde拼凑出来，
具体保存的时候，原文件用0序列文件名上传保存，余下的文件名序列上传0kb的占位文件在当前文件夹保存。

2、具体就是首先在驱动设置界面，增加“长文件名兼容”选项，勾选该选项，可以让用户设置具体的“最长文件名长度”，默认255。并且页面添加说明，明示“激活该选项后，会让超长文件名文件和文件夹在rclone无法兼容读取”
3、上传文件的时候，判断文件名是否超长，如果超长就按格式拆分拼接，譬如设置最长255，part.ABCDE.0占12位，从余下文件名截取255-12=243位字符拼接0序列，依次类推后续文件名序列，用0序列文件名上传保存源文件，再用后面的文件名序列分别上传几个0kb的文件。
4、读取的时候，遇到part开头的文件名，则判别需要拼接文件名显示，part文件对使用者透明，只显示拼接后的完整文件名
5、文件夹名和文件名逻辑一致

6、实现的时候，考虑一下能不能把数据加密、文件名加密、文件名分片几个功能解耦，如果可以的话，后续这几个功能项可以由使用者自由组合，crypt的文件名分片可以作为其他驱动的前置驱动，彻底解决超长文件名的问题，像目前chunk提的前缀过长issue也是对文件名超长的顾虑。

附加信息

No response

Start by locating the crypt driver settings and implementation, then compare its filename handling with the existing chunk driver's filename-prefix behavior. Define how upload, reading, and directory-name handling should split and reassemble names while preserving the stated rclone compatibility warning. Done means the option, configurable length, transparent reconstruction, and placeholder-file behavior are implemented and verified for files and folders.