As a site operator, you can request cookies to be set in the cookie jar of a browser visiting the site. You can choose to make persistence of those cookies across a session mandatory for your site to function (as it sounds like you have done by requiring session cookies are presented back to you to keep a user logged in). However, you do not "own" the cookie jar and you cannot control what other cookies (including both session and persistent cookies) may be presented to you along with the session cookies that you set. In general, your code should look for the cookies you expect and ignore any that you don't expect. It would not be good practice to take any action based on the presence of "extra" cookies that you weren't expecting because they are not under your control.
The user is the one who controls their cookie jar, with the assistance of the browser. They can choose to disable handling of cookies entirely (or use a client that does not support them). If you find that your own session cookies are not coming back when you expect them to be, it would be good in that case to let the user know it is because their client does not seem to support cookies, or to implement a fall-back plan for session management that does not require cookies, but in my opinion no warning message would be appropriate in case "extra" cookies received.
Since the user controls their browser, they can set any cookies they like in their browser by editing the cookie jar manually. If they set a cookie that would apply to your site's domain and path, the client will send those cookies along with the HTTP request to your site.
In addition, if your site shares any part of its domain with other sites, those other sites may set cookies that will be presented to your site as well. For example, if your site was accessible at: http://site1.example.com/ but there was another site accessible at: http://site2.example.com/, the operator of site2 could set cookies with the domain set to example.com in which case they would be presented both to site1 and site2 (and any other subdomain of example.com).
Even if your site is accessible only on a domain you control, there is a possibility that a browser could have "supercookie" prevention disabled (cookies that are set on a top-level domain name such as ".com"). Normally, browsers should disallow those "public suffixes" (see https://www.rfc-editor.org/rfc/rfc6265#section-5.3) but it may be possible to disable that in advanced browser settings.
To avoid potential attacks on your site through cookies from other domains, it is good practice for you to verify that the cookie domain and path match as well as the cookie value itself.
