Scrum and Kanban are actually fairly different, but there has been a misconception that there are two frameworks here competing with each other, and this is wrong.
First, the short answer: Scrum and Kanban attempt to solve different problems and can be used together very well. Also, the direct answers to your questions are at the bottom of this post.
Scrum is a very loose framework designed for solving complex-adaptive problems (problems where you have to try things and adapt to find the answer) and its goal is to organize the team and the work in a way that helps them tackle these issues.
Kanban is a method for improving your process, regardless of what that process is. Scrum isn't very explicit (intentionally) on how to complete the work in the sprint, so no conflict.
Scrumban goes poorly when you take what you feel like out of each framework and drop the stuff you don't want to do. On the other hand, if you combine them, they can be great. What I've usually seen that look like is this:
A Scrum team understands the core mechanics of scrum, but has problems with the flow of work through the sprint. Maybe a lot of work piles up at the end or sometimes key items get missed. Either way, they want to improve how they get the work on in scrum. So, instead of a basic Ready-Doing-Done board, they visualize their workflow, design a board off of it, apply WIP limits and start tracking cycle time. Thanks to the Kanban part, they find that certain types of work get stuck in an ugly back-and-forth cycle with another group and they take steps to try to improve on that problem. And there, a scrum team uses kanban to improve how they do the work.
So, to your specific questions:
Does scrum allow any number of WIP items at a time?
Scrum uses the timebox of the sprint to limit overall WIP to whatever can be completed. Many teams find this constraint inadequate and apply additional WIP limits to steps in the development process or even team members.
Should kanban stories be assigned points or just lead estimates?
I'm not aware of any "right" answer to this. Many purely Kanban teams do not use estimates, but estimates don't get in the way of Kanban either. Usually when used to improve the team's process in scrum, the points are kept.
What does kanban say about INVEST? Specifically, vertical slices of
functionality?
Nothing. However, as Kanban is built on Lean principles, if you are doing work without creating value, you would be violating a number of Lean principles and probably creating a lot of waste. A good practice for a Kanban team is to move deliverable items across the board, not work tasks.
Does the kanban backlog have a priority order (how are the stories
sequenced?)
Yes, the simple answer is top-first. There are some exceptions like if the team uses emergency lanes or other classes of service, but single-column top-first is a good place to start.
