[Bugfix] Drop service/2/ from the service configuration during dstack preset export

[peterschmidt85]

Fixes an issue introduced in #4152.

Steps to reproduce

1. Create a preset whose final service ships patches. The agent records them inside the preset directory under service/<k>/patches/, where <k> is the final-service attempt number.
2. Export it: dstack preset export 6900d9d7 -f qwen38-service.dstack.yml.

Actual behaviour

The exported configuration and the copied files keep the store-internal record layout, leaking the attempt numbering into the artifact:

files:
- local_path: service/2/patches/sglang/srt/layers/attention/aiter_backend.py.patch
  path: /patches/aiter_backend.py.patch

Expected behaviour

The export keeps only the structure under the record prefix, with the files next to the configuration:

files:
- local_path: patches/sglang/srt/layers/attention/aiter_backend.py.patch
  path: /patches/aiter_backend.py.patch

Collision fallback

Dropping the prefixes can merge paths that the record layout kept apart. Before writing anything, the export checks for that and keeps the full record layout for all files when:

• two different files would land on one exported path, for example service/1/patches/fix.patch and service/2/patches/fix.patch both becoming patches/fix.patch;
• a file would land on the configuration file itself.

Paths are compared case-insensitively: on macOS and Windows Fix.patch and fix.patch are the same file, so a case-sensitive check would let one copy silently overwrite the other. Each case has a test; verified end to end by deploying an exported preset on an MI300X and receiving a completion from the patched server.

🤖 Generated with Claude Code

[peterschmidt85]

Closing: any rewriting of the stored paths needs collision guards, while the record layout is the only design that needs none, since its files already exist at those relative paths on the exporting filesystem. The prefix also carries provenance: the export names the recorded attempt that produced it.