Any way to speed up a PK?
…would be responsible for 42.5% of the runtime if the optimizer's cost model exactly matched the performance characteristics of your hardware and the plan actually produced the number of rows, with the same distribution, as the optimizer expected. The cost numbers in execution plans for your version of SQL Server are always estimates, even in a post-execution (actual) plan.
Looking at the same plan operator with the row counts actually encountered:
…you can see that no rows arrived at the nested loops join driving the seek, so the seek was never asked to return any rows at all.
The cost percentages are there to indicate the operations the optimizer expected to be expensive. If it was wrong, it was wrong, and all bets are off: the whole basis for choosing the plan is suspect.
Look for operations that seem inefficient or produce a large number of rows as a starting point, and try to understand what could be done to make those more efficient. Often that means working with smaller parts of the query, and improving the indexes, statistics, and/or query text until performance is acceptable.