feat(settings): add custom domain settings for share and direct links

[yabo083]

Description / 描述

Add two new global settings to allow users to configure custom domains for share links and direct links:

• share_url_domain: Custom domain for share links
• direct_link_url_domain: Custom domain for direct links

添加两个新的全局设置，允许用户为分享链接和直链配置自定义域名：

• share_url_domain：分享链接的自定义域名
• direct_link_url_domain：直链的自定义域名

Motivation and Context / 背景

When OpenList is deployed behind a reverse proxy or accessed via different domains (internal vs external), users may want share links and direct links to use a public domain instead of the internal IP address.

For example:

• Internal access: http://192.168.0.107:5244
• Public share links: https://share.example.com

This allows users to share links that work externally without exposing internal network addresses.

当 OpenList 部署在反向代理后面或通过不同域名访问时（内网 vs 外网），用户可能希望分享链接和直链使用公网域名而非内网IP。

例如：

• 内网访问：http://192.168.0.107:5244
• 公网分享链接：https://share.example.com

这允许用户分享可以从外部访问的链接，而无需暴露内部网络地址。

How Has This Been Tested? / 测试

• Configured both settings with custom domains
• Verified share links use the configured share_url_domain
• Verified direct links use the configured direct_link_url_domain
• Confirmed empty settings fall back to default behavior (using location.origin)

Checklist / 检查清单

• I have read the CONTRIBUTING document.
  我已阅读 CONTRIBUTING 文档。
• I have formatted my code with go fmt or prettier.
  我已使用 go fmt 或 prettier 格式化提交的代码。
• I have added appropriate labels to this PR (or mentioned needed labels in the description if lacking permissions).
  我已为此 PR 添加了适当的标签（如无权限或需要的标签不存在，请在描述中说明，管理员将后续处理）。
  Labels needed: enhancement, Module: Settings
• I have requested review from relevant code authors using the "Request review" feature when applicable.
  我已在适当情况下使用"Request review"功能请求相关代码作者进行审查。
• I have updated the repository accordingly (If it's needed).
  我已相应更新了相关仓库（若适用）。
  • OpenList-Frontend feat: improve share page link generation with smart routing OpenList-Frontend#361
  • OpenList-Docs #XXXX

[hshpy]

反代配置X-Forwarded-Host或在config.json配置site_url

[xrgzs]

反代配置X-Forwarded-Host或在config.json配置site_url

这个需求场景应该是这样：家里云，内网IP访问，复制下载地址，返回域名

参考：

[hshpy]

反代配置X-Forwarded-Host或在config.json配置site_url

这个需求场景应该是这样：家里云，内网IP访问，复制下载地址，返回域名

参考：

这么小众，路由改下hosts...

[jyxjjj]

同认为小众，而且很多部分与基础设施重叠，软件不应该做基础设施做的功能，尤其是我从不认为任何软件在没有反向代理的情况下暴露公网是合适的。

[jyxjjj]

我目前也有类似的操作，是走内网DNS覆盖的。觉得比给软件增加基础设施要靠谱很多。功能的复杂性会带来更多维护成本和出现问题的概率。
(--我的场景是从GitHub和内网访问某个自有API，并同时禁止或允许从任意无法固定地址的公网访问。)

[yabo083]

​综合各位审查者的意见，我决定关闭此 Pull Request。
​理由是该功能的应用场景确实相对小众。不过我想补充说明一下我的使用初衷：在我的部署环境下，OpenList 主要作为内网资源的管理器，大部分流量请求都发生在局域网内。由于无法通过更改基础设施（如全局反代或 DNS）来满足“仅将特定内网资源通过公开域名开放给外部访问”的需求，我才尝试在 OpenList 本身进行功能增强。
我曾考虑过在反向代理层（如 Nginx）通过 sub_filter 替换响应内容，或者使用 Split-horizon DNS。但由于 OpenList 的内外部资源路径在协议层是同构的，基础设施很难在不解析业务逻辑的情况下，精准地只对‘分享链接’进行域名转换。
​虽然这可以通过复杂的边缘计算（Edge Functions）或重写插件实现，但对普通内网用户来说门槛极高。不过我尊重项目组保持核心代码精简的决定。
​感谢大家的评审建议。