Point 1. is more of a (DOM-based) self-XSS issue. And as you said, point 2. and 3. are really the same (the attack happens by visiting a URL).
A GET request via a link is the most common way to execute an XSS attack. The link could for example be send to a victim via email or posted in a forum.
But there are other ways. The defining characteristic of reflected XSS is that input is reflected, meaning that the server takes some sort of value from a HTTP request, inserts it into a HTML context in the response, and the browser then renders that response, thus executing the injected code.
POST-based reflected XSS
Reflected XSS can also be performed via POST requests (which are not protected from CSRF). Eg:
<form action="https://example.com/vulnerable" method="POST">
<input type="hidden" name="number" value="[XSS payload]" />
In the same manner, a GET request could be send via a form (by changing the
GET). An attacker might choose this approach if a POST request is required, or if they think that it is more likely that a user visits a page where they can post scripts, and less likely that they will click on a link to the victim site.
Your point 1. might be exploitable if the site is frameable. Some browsers - eg Firefox last I checked - allow the dragging of text into iframes (not out of them though).
By performing a clickjacking attack, an attacker could get a victim to "enter" the XSS payload and execute it.
Another way to execute a self-XSS would be to simply ask the user to post the payload ("can you post this long, HTML formatted post [containing an XSS payload] to your website?", "Can you upload this harmless image [whose filename contains an XSS payload] to your blog?", etc).
Session tokens as (non-) protection
do session tokens protect us from these approaches?
If your session tokens are always included in the URL, and the page doesn't reflected any input when the session token is missing (and the session token is securely generated), then that would indeed protect against (non-self) reflected XSS that send a victim a malicious link. In the same manner CSRF tokens protect requests against (non-self) reflected XSS.
However, now you have a new problem. Sensitive data in URLs is strongly discouraged. It can easily leak via referers, when users share links, etc. And once that happens, anyone could have access to that users account.