Fix: V5-suggested authors already in the library are not linked when author import is disallowed

[sebclark]

The bug

TryRecoverRestrictedMissViaV5 bails out as soon as allowAuthorImport is false:

if (!allowAuthorImport)
{
    return (null, suggestion, s.Reason);
}

var recoveredAuthor = TryGetOrImportSuggestedAuthorForRestrictedRecovery(...);

The existing-author lookup (FindByProviderId) lives inside TryGetOrImportSuggestedAuthorForRestrictedRecovery, below the early return - so any matching context with AllowAuthorImport = false (notably MatchingContextPresets.ForDownloaded, i.e. every completed-download import) can never link a V5 suggestion to an author already in the library. The file is rejected with No match in local library. Suggested author: <name> (<providerId>) even when that exact provider id is stored on a local author row.

This bites hard after the V3 cutover: the metadata server now answers with hc:-keyed author suggestions, while libraries built earlier hold authors added under other provider eras. On my install the completed-download queue filled with items blocked on suggestions for authors that were sitting in the library with the exact suggested hc: id (verified in the DB).

The fix

When allowAuthorImport is false, still perform a lookup-only resolve of the suggested provider id (new TryFindExistingSuggestedAuthor, no add path). If the author exists, run the same author-scoped strict match used by the import-allowed branch. Behaviour for genuinely-new authors is unchanged - nothing is auto-added.

Tests

New test in AuthorRestrictedV5RecoveryFixture: same scenario as the existing ...when_import_allowed test but with AllowAuthorImport = false. It fails on current develop (file lands unmatched with the suggestion) and passes with the fix (links to the existing author, matches the book). Full Core.Test suite green: 2853/2853.