fixup! status-quo story: Alan needs async in traits

Co-authored-by: Ryan Levick <[email protected]>

Author: zeenix

src/vision/status_quo/alan_needs_async_in_traits.md

@@ -46,7 +46,7 @@ After Alan finishes adding the new trait, he shows his work off to Barbara and m
 * handles lifetimes for you if the returned future is tied to the lifetime of some inputs.
 * boxes and pins the futures for you.
 
-which implementer will have to manually handle if they don't use `async_trait`. She decides to not worry Alan with this right now. Alan and Barbara are pretty happy with the results and go on to publish their crate which gets lots of users.
+which the implementer will have to manually handle if they don't use `async_trait`. She decides to not worry Alan with this right now. Alan and Barbara are pretty happy with the results and go on to publish their crate which gets lots of users.
 
 Later on, a potential user of the library wants to use their library in a `no_std` context where they will be providing a custom HTTP stack. Alan and Barbara have done a pretty good job of limiting the use of standard library features and think it might be possible to support this use case. However, they quickly run into a show stopper: `async-trait` boxes all of the futures returned from a async trait function. They report this to Alan through an issue.