Configure shared files and directories for SSH deployment releases

[shyim]

Parent: #1553 (under #1009).

User story

As a developer using SSH deployment, I want to configure persistent files and directories per environment, so that custom runtime data survives releases without forcing every project to use the same layout.

Dependencies and current status

Extends #1555. An implementation exists in the current working branch; review and merge are pending.

Configuration

environments:
  production:
    type: ssh
    ssh:
      host: example.com
      directory: /var/www/shop/current
      shared:
        files:
          - .env.local
          - install.lock
          - custom/runtime.ini
        # directories omitted: use the default shared directories

Acceptance criteria

• Expose environments.<name>.ssh.shared.files and .directories in configuration and the project JSON schema.
• Resolve each list independently: omitted uses Shopware defaults; an explicit list replaces those defaults; [] disables sharing for that category.
• Preserve explicit empty lists when writing and reading configuration. Existing local-override merge conventions remain intact; !override [] clears a list defined by the base configuration.
• Default files: .env.local, install.lock, public/.htaccess, public/.user.ini.
• Default directories: config/jwt, files, var/log, public/media, public/plugins, public/thumbnail, public/sitemap, public/theme.
• Reject unsafe/non-project-relative paths, duplicates, and parent/child overlaps across both lists before opening SSH.
• Only configured entries are shared. .env.local is not linked implicitly; install.lock remains release-local when it is not listed.
• Delegate runtime configuration validation to Deployment Helper rather than requiring one particular shared dotenv file.
• Removing a configured entry does not delete the old shared data. Existing-layout conflicts require explicit migration rather than moving live data silently.
• Cover defaults, replacement, disabled sharing, configuration round-tripping, path validation and repeated rollout with custom persistent data in tests.

Out of scope

Automatic live-data migration, deletion of unused shared data, and storage/permission management outside the deployment root.

Readiness checklist

• Acceptance criteria are defined.
• Backward compatibility: deployment commands remain experimental behind the deployment build tag.
• User-facing help/documentation reviewed.
• Tests added or adjusted and reviewed.