The Help should say "Side effects - Automatic commit" for the SQL Remote PASSTHROUGH statement. Here is a reproducible that proves the point:

BEGIN
UPDATE parent SET non_key_1 = 123 WHERE key_1 = 1; 
COMMIT;
SELECT @@VERSION, 'First SELECT', non_key_1 FROM parent WHERE key_1 = 1;
UPDATE parent SET non_key_1 = 456 WHERE key_1 = 1; 
PASSTHROUGH FOR site0001;
PASSTHROUGH STOP;
ROLLBACK;
SELECT @@VERSION, 'Second SELECT', non_key_1 FROM parent WHERE key_1 = 1;
END;

@@VERSION,'First SELECT',non_key_1
'9.0.2.3951','First SELECT','123'

@@VERSION,'Second SELECT',non_key_1
'9.0.2.3951','Second SELECT','456'

In case PASSTHROUGH mode is not allowed within a trigger (as Nick has stated), you may use other approaches to force indirect DML updates on replicated tables, say

• Triggering an event from within your trigger that would run in its own transaction context and would execute the passthrough statement (though that might be difficult to handle in case the original operation is rollbacked).
• Use the trigger to do the local update on table2 and additionally mark the updated row somehow and use a SQL Remote hook procedure like "sp_hook_dbremote_begin" to catch up on these marked rows later by making the update via PASSTHROUGH ONLY there.
• Get rid of the PASSTHROUGH mode altogether here - I guess (but that's a wild guess) an UPDATE PUBLICATION statement should influence the remotes as well - I guess what you are trying to achieve is similar to the requirements of "territory realignment", in the sense that you need to have changes written to the log to be replicated that are not directly handled that way...