Option 3: Place a either a unique constraint or unique index on the foreign key.
Uniqueness of the foreign key limits the cardinality of that side of the relationship to at most 1. I tested and confirmed that this is correctly scaffolded when using Sql Server and EF Core 5.0 in a database first scenario.
Why Option 3 May Be Preferable
Option 3 works for both 1-to-0..1 and 0..1-to-0..1 relationships. This means that you can use it quite readily on existing databases without having to change them.
0..1-to-0..1 relationships do occur quite naturally when the entities can exist in their own right before being linked. To extend the example above, if we allow system user accounts that are not related to any person, and we also have people for whom a user account has not yet been created, then that may best be modelled by a 0..1-to-0..1 relationship.
Option 2 remains a great option if you are certain you need a 1-to-0..1 relationship. You can migrate to option 3 later, but it will be more work.
Additional Notes
If you are implementing a [0,1]-to-[0,1] relationship, then your foreign key field will be nullable. A UNIQUE constraint on a nullable foreign key will usually allow multiple rows to contain a NULL because NULL is not a value in conventional SQL. However, Sql Server is an exception and will permit only one row to hold NULL in the foreign key.
The solution is to use a conditional UNIQUE INDEX rather than a UNIQUE CONSTRAINT on Sql Server. Your condition should apply the index only to rows that have a non-null value in the foreign key.
You might create such an index with SQL such as the following.
CREATE UNIQUE INDEX IX_User_Person
ON User (PersonId) WHERE PersonId IS NOT NULL;