Stop requeuing a folder on its own engine-generated feedback (#181)

[gnacho]

Closes #181.

Problem

On startup (and in general operation) the active folder visibly jumps around: the queue should run one folder at a time in config order and not come back to a folder that already had its pass, but in practice some folders re-ran immediately several times in a row while others waited (evidence: 8 engine runs within 27s, immediate re-queues not interval-triggered).

Root cause (verified)

nextcloudcmd writes its sync journal .sync_*.db inside the synchronized folder, and that tree is watched by the FsWatcher. Every run therefore emits self-generated LocalInotify events in two windows:

• During the run: request queued them and finished re-queued them as follow-up (feedback_followup_pending).
• During the 4s cooldown: request queued them via schedule_debounce; cooldown_finished saw a non-empty queue and started another run immediately.

Each run rewrites the journal, perpetuating the cycle (8 runs in 27s). The #165 suppression only covered feedback during a Conflict outcome; post-Success requeue and cooldown events escaped.

Fix

src/core/scheduler.rs only:

• request(): drop LocalInotify while running || preparing || in_cooldown - only a genuine post-cooldown change re-queues.
• finished(): removed the feedback_followup_pending/inotify_during_sync machinery and the feedback_followup parameter; uniform queue.discard(LocalInotify) for finished runs. Related fields and stop() cleaned up.

Testing

4 tests (3 new + 1 updated), red-green confirmed:

• finished_folder_with_only_self_generated_feedback_is_not_requeued
• local_feedback_during_cooldown_is_not_requeued
• conflicted_folder_does_not_rerun_on_its_own_feedback (the 6x real case)

Gate: 694 passed, clippy clean, fmt applied. Note: the #189 ETag gate already removed the interval re-scan without a change; this closes the separate engine-generated-local-feedback vector, so after its pass a folder only runs on a genuine change.