Accessing implicitly-created arrays

storage points to an array of std::bytes and, AFAIU, under current standard wording, reinterpretcast(storage) still does as far as the compiler is concerned (https://eel.is/c++draft/expr.reinterpret.cast#7 does speak about actual object but of pointer type).
You just need to respect alignment (which you do).
Using std::launder, the compiler does not know anymore what you are doing with the pointer. As far as it is concerned again, it gets back the memory location of a T. And it happens to be the one pointed by storage. It is only well defined if there is actually a T object is living there (the precondition you mentioned: https://eel.is/c++draft/ptr.launder).

So this is the correct way to access the objects within the storage.
Note: there are discussions to remove the need for this std::launder in your situation: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3006r1.html

Now you are right to distrust your constructat call.

Merely do: std::constructat(reinterpretcast(storage) + size, t);

It is equivalent to ::new (staticcast(storage)+ size) T(t); (https://eel.is/c++draft/specialized.construct#3)

So there is no need for a possibly invalid std::launder there.

Side note: I'm unsure if you are getting a proper array of T with data() (which would allow for pointer arithmetic) or if you merely get access to the first T object. https://eel.is/c++draft/allocator.requirements.general#36 seems to imply that the answer is yes:

[Example 1: When reusing storage denoted by some pointer value p, launder(reinterpret_cast(new (p) byte[n * sizeof(T)])) can be used to implicitly create a suitable array object and obtain a pointer to it. — end example]

But you still have to start the lifetime of the elements (as you do), except if T is an implicit lifetime type.