How to avoid Table Lock Escalation?
If we look at the actual plan, the current query is reading too much data from the table to be updated.  This is from the index seek on BoxTrackInfo:

This is an index seek on btid for each row that comes out of the scan of BlueTrackEvents.  Update locks are acquired as btStatusID is checked to see if the row qualifies for the update.  Only 1,401 rows qualify for the update, but many more locks are taken in the process - resulting in lock escalation to the table level.
You really want a different plan shape - to seek into the BoxTrackInfo table on btStatusID and then join to BlueTrackEvents, which should acquire significantly less locks.  To that end, adding an index like this should help:
CREATE NONCLUSTERED INDEX IX_btStatusID 
ON dbo.BoxTrackInfo (btStatusID)
INCLUDE (btType);

This should more efficiently locate qualifying rows, hopefully allowing the update to complete without lock escalation.

As a side note, the current execution plan validates the foreign key constraint on btStatusID using a merge semi-join:

This is probably not a big deal in your case, since there are only 267 rows in the LBoxTrackStatus table.  If that table were larger, you might consider adding a LOOP JOIN or FAST 1 hint to the query in order to get nested loops FK validation.  See this post for details:
Why am I getting a snapshot isolation issue on INSERT?