You have already stated, respectively listed what the issue could be:

OLE DB provider "SQLNCLI11" for linked server "LinkedServerName" returned message "Cannot generate SSPI context". Msg -2146893044, Level 16, State 1, Line 0 SQL Server Network Interfaces: The logon attempt failed

So what is SSPI? Microsoft describes it as:

In conjunction with its operating systems, Microsoft offers the Security Support Provider Interface (SSPI). The SSPI provides a universal, industry-standard interface for secure distributed applications.

^{Reference: Security Support Provider Interface (SSPI) (Microsoft Docs)}

Basically it's how an application authenticates itself, the user or other components against an endpoint asking for authentication.

In the Architectural Overview there is the description that ...

A variety of SSPs and packages are available. Windows ships with the NTLM security package and the Microsoft Kerberos protocol security package. In addition, you may choose to install the Secure Socket Layer (SSL) security package, or any other SSPI-compatible SSP.

^{Reference: SSPI Architectural Overview (Microsoft Docs)}

NTLM

When your old application starts in the other domain it will pass on the old NTLM SID value and compare it with what is stored in the SQL Server instance.

If there is a match [Domain/User] with a SQL Server Login [Domain/User] then SQL Server will let the user login to the relevant databases. SQL Server will do the same for a [Domain/User] that is assigned to a SQL Server Windows Group Login.

Kerberos

Kerberos relies on the ability of a user or service account being able to generate a token (of a request) and to compare this with a central provider to determine if a user is who he/she/them claim to be.

_{emphasis mine}

Kerberos V5 is based on the Kerberos authentication system developed at MIT. Under Kerberos, a client (generally either a user or a service) sends a request for a ticket to the Key Distribution Center (KDC). The KDC creates a ticket-granting ticket (TGT) for the client, encrypts it using the client's password as the key, and sends the encrypted TGT back to the client. The client then attempts to decrypt the TGT, using its password. If the client successfully decrypts the TGT (i.e., if the client gave the correct password), it keeps the decrypted TGT, which indicates proof of the client's identity.

^{Reference 1.1 What is Kerberos and How Does it Work? (MIT Kerberos V 5.0)}

Explanation Summary

So your Server A is trying to access Server B via a Kerberos Authentication but failling to succeed, because the SPN could be missing.

To achieve a successful authentication the Server(s) should have a Service Principal Name (SPN). Which is described as:

A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.

And a bit further down the possible root cause:

If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.

^{Reference Service Principal Names (Microsoft Docs)}

To Cut a Long Story Short

If either your application (host) and/or your SQL Server Instance are unable to register a Service Principal Name then your application/server will be unable to authenticate users via Kerberos and your linked server may fail.

Check the ERRORLOG of your SQL Server instance and verify that the SQL Server instance was able to register its own SPN. There will be an entry during the instance startup procedure.

The SQL Server Service Account can do this if it is a Domain Service Account and some other conditions are met. Some being:

The client and server computers must be part of the same Windows domain, or in trusted domains.

and

A Service Principal Name (SPN) must be registered with Active Directory, which assumes the role of the Key Distribution Center in a Windows domain. The SPN, after it's registered, maps to the Windows account that started the SQL Server instance service. If the SPN registration hasn't been performed or fails, the Windows security layer can't determine the account associated with the SPN, and Kerberos authentication isn't used.

^{Reference: Register a Service Principal Name for Kerberos Connections (Microsoft Docs)}

Output of successful SPN registration

2020-12-01 11:14:18.87 Server      
SQL Server is attempting to register a Service Principal Name (SPN) for the SQL Server service. 
Kerberos authentication will not be possible until a SPN is registered for the SQL Server service. 
This is an informational message. No user action is required.
...
2020-12-01 11:14:18.94 Server      
The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) 
[ MSSQLSvc/SERVERNAME.TG.CH ] for the SQL Server service.

If the service can't register the SPN, then:

Note

If the server can't automatically register the SPN, the SPN must be registered manually. See Manual SPN Registration.

Output of Unsuccessful SPN registration

2020-11-27 15:41:56.24 Server      
SQL Server is attempting to register a Service Principal Name (SPN) for the SQL Server service. 
Kerberos authentication will not be possible until a SPN is registered for the SQL Server service. 
This is an informational message. No user action is required.
...
2020-11-27 15:41:56.43 Server      
The SQL Server Network Interface library could not register the Service Principal Name (SPN) 
[ MSSQLSvc/SERVERNAME:INSTANCENAME ] for the SQL Server service. 
Windows return code: 0x200b, state: 15.
...
2020-11-27 15:41:56.43 Server      
The SQL Server Network Interface library could not register the Service Principal Name (SPN) 
[ MSSQLSvc/SERVERNAME:INSTANCEPORT ] for the SQL Server service. 
Windows return code: 0x200b, state: 15. 

Once your SQL Server instance has its SPN registered, then you should be up and running.

Solutions

Manual SPN Registration

Well you have to be a Domain Administrator or allowed to change Computer Account objects on the OU of the domain. Then you can run SETSPN with the relevant parameters:

setspn -A MSSQLSvc/host.domain.tld:1433 domain\accountname 

^{Reference: Manual SPN Registration (Microsoft Docs)}

Once an SPN has been configured for a service account, then you should be able to start the server again and access the database.

SPN registration requires a restart of the service.

Modifiy OU Object's Permissions

In order for the SQL Server's Service Account to create a SPN automatically in Active Directory it (the service account) should have the permissions to modify its own object (OU).

When the Database Engine service starts, it attempts to register the Service Principal Name (SPN). Suppose the account starting SQL Server doesn't have permission to register an SPN in Active Directory Domain Services. In that case, this call fails, and a warning message is logged in the Application event log as well as the SQL Server error log. To register the SPN, the Database Engine must be running under a built-in account, such as Local System (not recommended), or NETWORK SERVICE, or an account that has permission to register an SPN. You can register an SPN using a domain administrator account, but this is not recommended in a production environment. When SQL Server runs on the Windows 7 or Windows Server 2008 R2 operating system, you can run SQL Server using a virtual account or a managed service account (MSA). Both virtual accounts and MSA's can register an SPN. If SQL Server isn't running under one of these accounts, the SPN isn't registered at startup, and the domain administrator must register the SPN manually.

^{Reference: Register a Service Principal Name for Kerberos Connections (Microsoft Docs)}

Assigning the Permissions

To grant permission to modify SPNs

• Open Active Directory Users and Computers. To open Active Directory Users and Computers, click Start, click Run, type dsa.msc, and then press ENTER.
• Click View, and verify that the Advanced Features check box is selected.
• Click Advanced Features, if it is not selected. If the domain to which you want to allow a disjoint namespace does not appear in the console, take the following steps:
  • In the console tree, right-click Active Directory Users and Computers, and then click Connect to Domain.
  • In the Domain box, type the name of the Active Directory domain to which you want to allow the disjoint namespace, and then click OK. As an alternative, you can use the Browse button to locate the Active Directory domain.
• In the console tree, right-click the node that represents the domain to which you want to allow a disjoint namespace, and then click Properties.
• On Security tab, click Advanced.
• On the Permissions tab, click Add.
• In Enter the object name to select, type the group or user account name to which you want to delegate permission, and then click OK.
• Configure the Apply onto box for Computer objects.
• At the bottom of the Permissions box, select the Allow check box that corresponds to the Validated write to service principal name permissions, and then click OK on the three open dialog boxes to confirm your changes.
• Close Active Directory Users and Computers.

^{Reference: To grant permission to modify SPNs (Microsoft Docs)}

SPN registration requires a restart of the service. You should see a successful SPN registration in the ERRORLOG of the permissions are set correctly

Increase Kerberos Token Size

In some cases an account can belong to too many objects/AD groups/ ... which will result in a rather larger Kerberos Token. In these cases you might have to increase the max token size.... Symptoms may include:

A user who belongs to a large number of security groups has problems authenticating. When authenticating, the user may see a message such as HTTP 400 > - Bad Request (Request Header too long). The user also has problems accessing resources, and the user's Group Policy settings may not update correctly.

But

Under similar conditions, Windows NTLM authentication works as expected. You may not see the Kerberos authentication problem unless you analyze the Windows behavior. However, in such scenarios, Windows may not be able to update Group Policy settings.

^{Reference: Problems with Kerberos authentication when a user belongs to many groups (Microsoft | Docs)}

Fix

On a domain controller that is running Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012, you can use Group Policy to add the following registry entry to multiple computers:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Entry: MaxTokenSize
Data type: REG_DWORD
Value: 48000

^{Reference: How to use Group Policy to add the MaxTokenSize registry entry to multiple computers (Microsoft | Docs)}

Solution Based on Referenced Answer and Multiple Updates to Question

After reading through all the additional information in the question and other answers, I have come to the conclusion that all possible solutions have been looked at. I think this Q & A could possibly be closed as duplicate of the question which you referenced with Hannah Vernon's answer.

However I would like to provide a solution on how to apply a fix for this issue.

When an instance of the SQL Server Database Engine starts, SQL Server tries to register the SPN for the SQL Server service. When the instance is stopped, SQL Server tries to unregister the SPN. For a TCP/IP connection, the SPN is registered in the format MSSQLSvc/:.Both named instances and the default instance are registered as MSSQLSvc, relying on the value to differentiate the instances.

For other connections that support Kerberos the SPN is registered in the format MSSQLSvc// for a named instance. The format for registering the default instance is MSSQLSvc/.

Manual intervention might be required to register or unregister the SPN if the service account lacks the permissions that are required for these actions.

^{Reference: Register a Service Principal Name for Kerberos Connections (Microsoft | SQL Docs)}

Interesting Bit of Information

One thing that should be noted is granting these rights is not recommended (see http://support.microsoft.com/kb/319723) if SQL Server is clustered or if you have multiple domain controllers as latency in Active Directory replication can cause connectivity issues with your SQL Server instance.

^{Reference: Register a SPN for SQL Server Authentication with Kerberos (MSSQLTips.com)}

So the solution would be to actdually revoke the Service Account the ability to modify its own object, which would deny it the possibility of removing an SPN during failover.

• Start Active Directory Computers and Users and make sure you are looking at the Advanced View version.

• Open up the Service Accounts properties and switch to the Security tab.

• Select the Self item from the Group- or Username section and look at the Permissions for SELF.

• Remove the Full Access and/or Write and/or Write servicePrincipalName and/or Write Public Information permission if they are selected.

• The Write servicePrincipalName might be located in the Advanced section of the Permissions (click on the button Advanced).

This should prevent further issues when the cluster does a failover because instances are restarted, which would result in the SPN being de-registered.