Fix #108: Fix file ownership on Haiku after rsync

[mr-raj12]

rsync -auz preserves numeric UIDs. On the Linux runner files are owned by uid 1001, inside the Haiku VM the user is uid 0.
Git 2.35.2+ won't run in a directory owned by a different user.
The mismatch was always there, just never triggered. setuptools 78.1.1 calls setuptools_scm earlier in pip install -e . than older versions did, so git gets invoked during install and hits the check for the first time.

Fix adds a synchronizePaths override in the Haiku VM to run chown after rsync as same pattern as the existing setupWorkDirectory override in the same file, no other OS touched.

Adds a CI job test-haiku-file-ownership that boots Haiku and asserts find . -nouser returns nothing verifying no files in the work directory are owned by an unresolvable uid after rsync.

@manxorist identified the issue and proposed the chown approach in #108, this is just the implementation.

borgbackup/borg#9563 worked around it with
git config --global --add safe.directory on their end, which is how we ran into this.

Closes #108

[jacob-carlborg]

I would prefer an end-to-end test as well, to make sure it's working properly. A new job in the GitHub action workflow, something like:

action/.github/workflows/ci.yml

Line 306 in e3d398c

test-cpu-count-config:

.

[manxorist]

As mentioned in #108 (comment), another option might be to tweak the rsync parameters, but I have not looked at that at all.

[jacob-carlborg]

Thanks.