Querying using a [NotMapped] property that maps directly to a mapped property

I have several link entities which are bridging tables for many-many relationships. Mock example below. The property names are fixed (existing project), but I have a common interface across the bridging tables that are implemented by remapping an entity property to a notmapped property.

Is it possible to set up the remapping (through expressions or events or any other means) so that the interface property can be used in Linq queries as a proxy for the underlying property and resolved server side? E.g. make the following work:

public List<T> GetClientFilesForRelated<T>(int RelatedId) where T:IFileRelated, class
{
    return _context.Set<T>().Where(x=>x.RelatedId==RelatedId).ToList()
}


public class File
{
    public int FileId { get; set; }
}
public class Client
{
    public int ClientId { get; set; }
}
public class Company
{
    public int CompanyId { get; set; }
}
public class ClientFile : IFileRelated
{
    public int ClientFileId { get; set; }
    public int ClientId { get; set; }
    public int FileId { get; set; }
    [NotMapped]
    public int RelatedId { get => ClientId; set => ClientId = value; }
}

public class CompanyFile : IFileRelated
{
    public int CompanyFileId { get; set; }
    public int CompanyId { get; set; }
    public int FileId { get; set; }
    [NotMapped]
    public int RelatedId { get => CompanyId; set => CompanyId = value; }
}

public interface IFileRelated
{
    public int FileId { get; set; }
    public int RelatedId { get; set; }
}

Short answer, No. [NotMapped] means exactly that, EF is not expecting to, nor can translate that into SQL. What you can do would be something like this:

public class ClientFile : IFileRelated
{
    public int ClientFileId { get; set; }
    [Column("ClientId")]
    public int RelatedId { get; set; }
    public int FileId { get; set; }
}

public class CompanyFile : IFileRelated
{
    public int CompanyFileId { get; set; }
    [Column("CompanyId")]
    public int RelatedId { get; set; }
    public int FileId { get; set; }
}

Which should work fine, but won't be the most intuitive when looking at the two.

Your repository or such method to get the files is already misleading:

public List<T> GetClientFilesForRelated<T>(int RelatedId) where T:IFileRelated, class

Where the name implies "Client" files but really intends to return Client or Company files. Honestly I highly recommend avoiding Generic implementations like the Generic Repository when it comes to EF. Simply have:

List<ClientFile> GetClientFiles(int clientId);

and

List<CompanyFile> GetCompanyFiles(int companyId);

Already it should be quite evident that these are simpler, single-purpose methods. There isn't really a case for worrying about DRY as DRY is a concern to avoid duplicating identical code. These are not identical concerns, they are merely similar. Generic methods are an excellent tool for dealing with classes that can be used completely interchangeably. Avoid the temptation to squeeze every shape peg into a round hole just because they seem similar to one another.