Not really. In C++,
std::move() performs a cast to rvalue reference, which in some cases allows a move to take place, but it's very different from the move itself. In Rust, the r/l/x/pr/plvalue reference taxonomy is completely absent and Rust references have no special behavior when it comes to move semantics, so the very concept of an "rvalue reference cast" has no meaning.
What is true is that a "move" in C++ is conceptually pretty similar to a "move" in Rust, but the rules for when they happen and what they do are completely different (in particular, Rust's rules are far simpler). https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html is the canonical explanation of basic ownership and borrowing in Rust, including moves, so just read that.
That's largely a separate issue, but it mostly boils down to "actually C++ would need it to if it wanted to guarantee memory safety". The core problem that Pin solves is that some types simply cannot be moved safely, but Rust assumes anything can be moved. C++... sort of does too, but it also assumes that you the programmer will simply know not to move things that silently lead to UB after being moved.
If you're talking about the
x: [u8; 128], then yes, that really is a fixed-size array inside the
AsyncFuture struct without any pointers or other indirection, just like in C or C++.
In principle, yes, and there are languages that essentially do this to handle features like async/await or coroutines. But of course that requires potentially doing a dynamic memory allocation on every single async/await, which would not be a "zero-cost abstraction".
For more on why
await works the way it does, and needs to work the way it does to be truly zero-cost, see alice's link.