Unless you have "Email package size:" set to zero in the phpBB ACP Email Settings page, it's http://mysite.com/cron and http://mysite.com/cron.php which end up actually sending the emails. Note these are just the base URLs, and there will be additional variable parameters present like "?cron_type=xxxxxxxx".
Viewing a page on phpBB doesn't always include an invocation of the cron URL. But it certainly could make sense that if a page is being cached and presented more times / to more visitors than phpBB intended, if the page that got cached did also happen to include a cron URL invocation, then everyone who received the cached copy of the page would have all tried to invoke that same cron URL.
But that doesn't immediately explain "and so I received duplicate notification emails." The "send queued emails" cron task might indeed have been run multiple times when phpBB didn't intend this to happen. But if the first invocation successfully sent the queued emails, those additional invocations should have just found that the mail queue was empty, rather than "so we will send the same notifications again."
So it still feels like there is some other ingredient here that we don't understand yet. Maybe a different way to test "is the cron URL being cached and invoked multiple times" being involved here would be to simply change "Email package size:" to zero in the phpBB ACP Email Settings page. So that all the notification emails will get sent "immediately" during the session of whomever is actually posting the message or event that triggers notification; rather than just queuing the emails to be sent later.