Bug: OpenBSD locally-originated directory moves are propagated as delete-and-recreate operations instead of OneDrive moves

### Describe the bug

While validating OpenBSD support during the extended Issue #3767 / PR #3794 test programme, a separate OpenBSD-specific behaviour has been identified in the filesystem monitoring path.

This issue is **not currently believed to be caused by PR #3794**. Evidence from earlier OpenBSD testing showed the same general signature — local deletes and creates with no recognised local moves — and the equivalent workload behaves correctly on Linux and FreeBSD.

## Problem

When a directory is moved locally on OpenBSD while the client is running in monitor mode, the move is not being recognised as a local move.

For example, a local operation equivalent to:

```text
random_files_openbsd/incoming/
→
random_files_openbsd/moved/
```

should be detected as a move and propagated to Microsoft OneDrive as a server-side move/rename.

Instead, the OpenBSD filesystem monitoring path currently appears to present the operation to the client as:

```text
DELETE random_files_openbsd/incoming/

CREATE random_files_openbsd/moved/
```

The client consequently performs the equivalent online operations:

```text
delete old directory from OneDrive
create new directory on OneDrive
upload all child files again
```

rather than issuing a normal OneDrive move operation.

## Controlled reproduction evidence

This was reproduced during a two-client controlled test:

```text
Ubuntu
normal bidirectional monitor
local mutation generator enabled

OpenBSD
normal bidirectional monitor
local mutation generator enabled
```

Each system owned an independent directory tree.

At the interim Stage 4 checkpoint, Ubuntu had correctly recognised and propagated:

```text
54 local directory moves
54 corresponding Microsoft OneDrive move operations
```

OpenBSD, however, had:

```text
0 "[M] Local item moved" events

56 source directory deletions
56 destination directory creations
560 child file uploads
```

The 560 uploads correspond exactly to:

```text
56 moved generation directories × 10 files per generation
```

The generation IDs also correlate exactly:

```text
local mv incoming/ → moved/

became:

delete incoming/ online
create moved/ online
upload all 10 files again
```

This is therefore not currently behaving as an occasional race. During the observed test window it occurred for every OpenBSD-originated directory move.

## Example behaviour

A generated directory is moved locally:

```text
random_files_openbsd/incoming/b992be2ae69769ea81572a5140be1437
→
random_files_openbsd/moved/b992be2ae69769ea81572a5140be1437
```

Instead of logging a local move, OpenBSD reports the source path as deleted:

```text
[M] Local item deleted:
./random_files_openbsd/incoming/b992be2ae69769ea81572a5140be1437
```

and deletes the existing OneDrive item.

The destination subsequently appears as a newly-created local directory and is scanned for new content:

```text
[M] Local directory created:
./random_files_openbsd/moved/b992be2ae69769ea81572a5140be1437

Scanning the local file system ... for new data to upload
```

The directory and its child files are then recreated online.

## Important distinction: remote moves work correctly

This does **not** mean that all move operations are broken on OpenBSD.

Remote/online moves received from Microsoft OneDrive work correctly.

During the preceding controlled Stage 3 test, Ubuntu generated 70 genuine remote directory moves.

OpenBSD received all 70 correctly as:

```text
Moving random_files_ubuntu/incoming/
to random_files_ubuntu/moved/
```

The local filesystem activity caused by those application-performed moves subsequently produced OpenBSD/kqueue delete/create notifications, but those events were safely contained by the client's database/state checks and did not result in false online operations.

The defect is therefore specifically associated with:

> **locally-originated moves being detected through the OpenBSD filesystem monitoring path.**

## Comparison with FreeBSD and Linux

This behaviour does not appear to be an inherent limitation of using kqueue.

During the earlier 24-hour three-platform validation:

```text
Fedora/Linux:
620 local moves recognised

Ubuntu/Linux:
610 local moves recognised

FreeBSD/kqueue:
608 local moves recognised
```

FreeBSD therefore successfully recognises local directory moves while also using the kqueue backend.

OpenBSD, using an equivalent mutation workload, currently produces no recognised local move events and instead processes the operation as deletion plus creation.

The differentiating behaviour therefore appears specific to the OpenBSD filesystem-event implementation/path rather than to kqueue support generally.

## Expected behaviour

A local directory rename or move on OpenBSD:

```text
mv incoming/ moved/
```

should be correlated by the monitor as a single local move operation.

The client should then update Microsoft OneDrive using the normal server-side move/rename mechanism.

Conceptually:

```text
local directory move
↓
filesystem monitoring
↓
[M] Local item moved
↓
Microsoft OneDrive move
```

## Actual behaviour

Currently:

```text
local directory move
↓
OpenBSD filesystem monitoring
↓
DELETE old path
CREATE new path
↓
delete old OneDrive item
create new OneDrive directory
re-upload all child files
```

## Impact

The final filesystem state can still converge, but the behaviour is incorrect and inefficient.

Potential consequences include:

* unnecessary deletion and recreation of OneDrive objects;
* complete re-upload of directory contents after every local directory move;
* unnecessary Microsoft Graph API traffic;
* unnecessary network transfer;
* changed OneDrive object IDs;
* possible loss/change of item version history or associated metadata;
* increased opportunity for transient download races on other synchronising clients;
* substantially more reconciliation activity than a true server-side move requires.

During the controlled test, the receiving Ubuntu client also experienced transient HTTP 404 download races exclusively against the rapidly changing OpenBSD-originated tree. These subsequently self-healed, but the delete/recreate behaviour substantially enlarges the race window compared with a normal server-side move.

## Likely investigation area

The issue appears to sit somewhere in the OpenBSD-specific local filesystem notification/move-correlation path:

```text
OpenBSD kqueue event semantics
↓
runtime/filesystem notification implementation
↓
OneDrive monitor event abstraction
↓
local move correlation
```

This should not yet be interpreted as an OpenBSD kernel defect.

The important current observation is simply that the same application correctly correlates moves on Linux and FreeBSD, while equivalent OpenBSD-local directory moves currently emerge from the monitoring layer as independent delete and create events.

## Relationship to Issue #3767 / PR #3794

This issue was discovered while performing extended validation for #3767 / #3794, but should be treated separately.

PR #3794 is actually containing the secondary reconciliation effects correctly:

* remote moves received by OpenBSD are handled correctly;
* delete/create echoes caused by application-performed moves are contained;
* no cross-client delete/recreate/re-upload feedback loop has been observed;
* no cross-owner false upload/delete activity has been observed.

This issue concerns the **originating OpenBSD local move detection path**, rather than the remote reconciliation defect addressed by #3794.

### Operating System Details

```shell
OpenBSD 7.9
```

### Client Installation Method

From Source

### OneDrive Account Type

Personal

### What is your OneDrive Application Version

N/A

### What is your OneDrive Application Configuration

```shell
N/A
```

### What is your 'curl' version

```shell
N/A
```

### Where is your 'sync_dir' located

Local

### What are all your system 'mount points'

```shell
N/A
```

### What are all your local file system partition types

```shell
N/A
```

### How do you use 'onedrive'

N/A

### Steps to reproduce the behaviour

N/A

### Complete Verbose Log Output

```shell
N/A
```

### Screenshots

N/A

### Other Log Information or Details

```shell
N/A
```

### Additional context

N/A