Support Adobe Lock Files in the classic sync engine (.idlk, .prlock)

[i2h3]

Situation

Follow-up to #10237, which adds Adobe lock file support to the macOS File Provider extension.

That work is scoped to the File Provider only. The classic (csync) sync engine — used on
Windows, Linux, and on macOS when the File Provider is disabled — does not yet handle Adobe
lock files, so they are still uploaded to the server and synced to collaborators.

Known Adobe lock file patterns

App	Extension	Naming pattern	Trigger
InDesign	.idlk	~{basename}~{random token}(.idlk	Opening any .indd document
InCopy (checkout)	.idlk	~{basename}~{random token}(.idlk	Checking out an .icml story
Premiere Pro	.prlock	{basename}.prlock	Opening any .prproj project

(See #10237 for the full research, including which Creative Cloud apps create no lock files.)

How the File Provider handles them (for reference)

In the File Provider, isLockFileName(_:) was extended to recognise .idlk/.prlock, so they
are routed through the existing lock-file lifecycle: kept local (never uploaded) and — when the
server supports locking — the guarded document is locked on the server, mirroring the
Office (~$…) / LibreOffice (.~lock.…#) behaviour. Because Adobe lock names drop the
document's extension, the guarded document is resolved by matching a sibling file by base name.

To Do (classic sync engine)

• Exclude .idlk and .prlock from sync in the classic engine — e.g. add *.idlk and
  *.prlock to sync-exclude.lst, alongside the existing ~$* and .~lock.* entries.
• Decide whether the classic engine should also lock the guarded document on the server
  like it does for Office lock files (FileSystem::filePathLockFilePatternMatch /
  isMatchingOfficeFileExtension in src/libsync/filesystem.cpp), or simply exclude the
  lock files from sync. Note that the Adobe document name is not encoded in the lock file
  name, so server-side locking requires the sibling-lookup approach used in the File Provider.