It's not possible to interact with an http-only cookie from the browser, and for good security reasons.
However, I managed to resolve the design need (checking for login prior to sending API request) by altering the one API call where I would not know for certain what the login status is.
The Vue store:
The Vue store is meant to be a convenient location for an SPA to store such a flag (logged in or not), however, the store is completely erased and re-established with each Vue instance, which means a new browser window / tab, refresh, or other unexpected event that triggers a browser refresh.
There are two potential solutions, the second of which of which I've implemented in my own SPA:
Two Solutions
1) Don't touch your back end code. Use vue-cookies to have the client browser set a cookie once a login has been established (this would be completely separate from the http-only cookie that the back-end API server needs).
This cookie should still exist after a browser refresh. I did not use (or try) this approach, however, as I didn't want to mess around with altering my front-end to check a local cookie each time I want to check for login status.
The front end code could use this cookie to figure out if the person is still logged in or not.
2) Another, separate approach is to short-circuit the normal back-end API check for authentication only for that specific route's controller, but not for any other route.
Here's how a 'short-circuit' on the back-end would work:
In the case of that specific route's controller method, have it first check for existence of the user in the request, and then return a 200 but with a status of "false" or some other variable which also appears in the success response.
It's counter-intuitive, and sort of strays from the meaning of a 200 response, but this gives the front end Axios call something to grab onto other than just a standard error response.
NOTE: I call it a "short-circuit" because if the back-end API route's controller method has a lot of code, making this check the FIRST thing it does will avoid the costly part of the call.
This approach works perfectly for my needs and doesn't require a new or secondary API call.