Why does Entity Framework not handle a 1:Many when deleting the object in the many

So here's my EF 1:Many setup

public class Event
{
	public int Id { get; private set; }
	public Interest? Interest { get; set; }
	public int? InterestId { get; set; }
}

public class Interest
{
	public int Id { get; private set; }
	public ICollection<Event>? Events { get; set; }
}

So an Event may have an Interest. And an Interest has many events. Now when I call the following:

using (var context = new TrackingDbContext(builder.Options))
{
	var interest = context.Interests.Find(pkInterest);
	context.Interests.Remove(interest);
	context.SaveChanges();
}

I get the following exception:

Microsoft.Data.SqlClient.SqlException
The DELETE statement conflicted with the REFERENCE constraint "FK_Events_Interests_InterestId". The conflict occurred in database "TestHoweInterest_2", table "dbo.Events", column 'InterestId'.

I can avoid it by adding the following code inside my DbContext.SaveChangesAsync() override:

var deletedInterests = ChangeTracker.Entries<Interest>()
	.Where(ei => ei.State == EntityState.Deleted)
	.Select(ei => ei.Entity).ToList();

foreach (var item in deletedInterests)
{
	var listEvents = await Events
		.Where(e => e.InterestId == item.Id)
		.ToListAsync();
	foreach (var eventOn in listEvents)
		eventOn.Interest = null;
}

My question is, why do I need to do this? Isn't there some way to tell EF that if an Event.Interest is being deleted, then null that FK?

And if there is no way to have this handled by the DB, is the code above the best way to address this? Note, I do not want to have a rule of make sure you null those values in the application first - that would cause this work to be repeated and if someone forgot - bug.

Solution thanks to @StevePy below.

public class InterestConfiguration : IEntityTypeConfiguration<Interest>
{
	public void Configure(EntityTypeBuilder<Interest> builder)
	{
		builder.HasMany(i => i.Events)
			.WithOne(e => e.Interest)
			.OnDelete(DeleteBehavior.SetNull);
	}
}

EF can manage cascading behaviour, or it can be set to let the database manage it. (if supported) The catch is that for EF to manage it, the DbContext needs to know about, as in, be tracking the related entities.

Cascade behaviour options can be found here: https://learn.microsoft.com/en-us/ef/core/saving/cascade-delete

Scroll down to "Impact on database schema" for the meat of the options. Typically I use the database-side options which would be "Cascade" or "SetNull" on the delete behaviour. "SetNull" looks like what you would want. In situations where you cannot introduce the database-side behaviour, you can use the "ClientCascade" or "ClientSetNull" to tell EF to manage the cascade, however when dealing with an aggregate root type entity like a one to many where you are deleting the "One" and want a flow-on effect to the "Many", you need to load the complete aggregate root. This means, eager load your aggregate:

using (var context = new TrackingDbContext(builder.Options))
{
    var interest = context.Interests
        .Include(x => x.Events)
        .Single(x => x.Id == pkInterest);

    context.Interests.Remove(interest);
    context.SaveChanges();
}

So in a nutshell, if you configure the cascade with DB-Side behavior your cascade delete or #null should work without needing to eager load the relationships. If you want to leverage EF to perform the cascade then eager-load the relationships with Include.

This is one reason to just never bother with the Find method as this provides no option to eager load aggregate root relationships.