The query uses an adaptive plan. This lets the optimizer switch between nested loops or a hash join at runtime. This often leads to a table appearing twice in the plan. It's only accessed once depending on the join the database uses.
You can see this from the STATISTICS COLLECTOR operation at line 23 in the SQL monitor report. This line is missing from the DBMS_XPlan report. So you're seeing the final plan after the database has chosen which join method to use.
Assuming both plans are from the same child cursor as Narendra notes, you can view the full adaptive plan by calling DBMS_XPlan with the +ADAPTIVE option:
e.g.
select * from dbms_xplan.display_cursor( ..., format => 'ALLSTATS LAST +ADAPTIVE');