Core component of SQL Server for storing, processing, and securing data
AFAIK, that's by design. As per https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-18452-database-engine-error?view=sql-server-ver17 this behavior is expected when you use the SQL Server's FQDN with Windows Authentication.
The hostname can work because Windows can establish the connection using local/workgroup credentials. When you specify hostname.domain.com, Windows Authentication attempts to authenticate the Windows identity against the domain associated with that FQDN. A workgroup computer does not have the domain trust relationship required for that authentication, so SQL Server receives credentials that cannot be validated and returns 18452.
You can obviously work around this by using hostname, SQL Server Authentication, if enabled and permitted, or by running SSMS under domain credentials from the workgroup computer, for example with runas /netonly using a domain account. The latter should allow you to use remote Windows authentication with domain credentials even though the workstation itself remains in the workgroup.
If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
hth
Marcin