Impacts of a full table scan on temp tablespace

I am working on a query being run in Oracle 19c. The particular query has many FTS hints and the query routinley runs out of temp space, even though there isn't a lot of rows returned.
I'm wondering what impact one or many full table scans has on temp space?

In the query below, will the query engine return every row from both the ales and book_author tables and then apply the where clase, or will the where clause be executed first and limit the number of rows retuned. What if there was a order by clause added?

select /*+ FULL(a) FULL(b) */
 b.author_key
 from
   sales a,
   book_author b
where
   a.book_key=b.book_key

select /*+ FULL(a) FULL(b) */  b.author_key  
  from    sales a,    
          book_author b 
 where    a.book_key=b.book_key

Assuming Oracle chooses a hash join, this will read 100% of the sales table (or actually, 100% of the rows with a non-null book_key, as because you have an inner join and NULL never equals NULL, Oracle will implicitly add a "WHERE book_key IS NOT NULL" in hopes of reducing the size of the inputs). It will then (the order could be reversed) do the same thing to book_author. These full table scans do not use temp space. You pay their cost in (mainly) I/O and some CPU.

The results of each row source will then be joined together using the hashing mechanism on the join key (book_key), which operation is CPU and memory intensive, and often requires temp space if insufficient PGA is available per process. That will require additional read/write I/O to temp. The result of that hashing operation will be only the rows that have a match on both sides (inner join).

Adding an order by will require additional sorting, which unless you have sufficient PGA assigned will also be done in temp space. In general, don't throw unneeded ORDER BY clauses on your SQL, they have a cost.