4. I think there are a few different ways you can check if a table is registered with the geodatabase or not. The way I do it is right click on the table in the Catalog pane. If the Register with Geodatabase option is shown in the right-click menu, then that means it's not registered. If that option is missing, then it is already registered.
Of course, if you know for sure that the underlying SQL Server database isn't a geodatabase, then that answers your question, too.
This table isn't registered with the geodatabase:
I think maybe the missing object_id might be causing an issue, the exported local version of the table (dataset 2) works and that has an object id field.
You could try creating a query layer in your APRX/Project on the second table. When creating a query layer, Pro will ask you what field is the unique ID field. That field will be treated as if it is an ObjectID field. You could try using the existing ID field in your table that has unique values as the unique ID field. If that doesn't work, you could try generating an integer field on the fly via SQL in the query layer. In Oracle, it'd be:
select
cast(rownum as int) as unique_id,
my_id,
...
The ROWNUM pseudocolumn is an Oracle-specific thing. So you'd need to figure out what the equivalent is in SQL Server.
Maybe Pro will behave better when joining to a query layer, compared to joining to a standalone table that isn't registered with a geodatabase (such tables are referred to as "database tables" instead of "geodatabase tables" in the Esri documentation).