matchPosts() cannot match files uploaded by deleted users

[pierres]

Summary

FileRepository::matchPosts() joins fof_upload_files to posts with actor_id = user_id. This means files uploaded by users who have since been deleted (or files embedded in another user's post) can never be matched — and a subsequent --cleanup will delete them.

Steps to reproduce

1. User A uploads an image in a post
2. User A's account is deleted (but their posts remain)
3. Run php flarum fof:upload --map --cleanup
4. The file is deleted because --map couldn't associate it with any post

Root cause

In src/Repositories/FileRepository.php, matchPosts() uses:

->leftJoin('posts', function (JoinClause $join) use ($table, $db, $prefix) {
    $join
        ->on("$table.actor_id", '=', 'posts.user_id')  // ← only matches posts by the uploader
        ->where(function ($q) use ($table, $db, $prefix) {
            $q->where('posts.content', 'like', $db->raw("CONCAT('%', $prefix$table.url, '%')"))
              ->orWhere('posts.content', 'like', $db->raw("CONCAT('%', $prefix$table.uuid, '%')"));
        });
})

The actor_id = user_id constraint limits matching to posts authored by the file's uploader. When that user is deleted (posts.user_id becomes NULL or the user row is gone), the join produces no matches.

This also affects a secondary scenario: if user B quotes or embeds a file originally uploaded by user A, --map won't find that association either.

Suggested fix

Remove the actor_id = user_id join condition. The content matching (LIKE '%url%' OR LIKE '%uuid%') is already sufficient to correctly associate files with posts. The same fix should be applied in matchFilesForPost() if a similar constraint exists there.

The same issue exists in the 1.x branch.

Environment

• Found while reviewing matchPosts() after PR [2.x] fix: correctly map and clean up files for all upload templates #459 (which fixed URL/UUID matching but left the join condition unchanged)
• Also related to the draft PR feat: delete orphaned files when their post is deleted #468 (orphan deletion on post delete), which uses pivot rows instead of content scanning and would not be affected