chore(docs): Updated gatsby-for-ecommerce (#29676)

Fixed a minor typo

docs/docs/conceptual/gatsby-for-ecommerce.md

@@ -32,7 +32,7 @@ And with Gatsby’s pre-built integrations, it can pull data in from all of thes
 
 E-commerce tends to have a number of specific requirements. When building a Gatsby site (or other decoupled/JAMStack site, for that matter) sourced from an ecommerce backend like Shopify, developers will typically have to think through a few additional touchpoints between the systems:
 
-- **Persisting a cart across site pages and between sessions** (ie, if the user closes their browser and reopens it tomorrow, the items should still be there). This can handled either through local-storage or through the shopify-buy JS library.
+- **Persisting a cart across site pages and between sessions** (ie, if the user closes their browser and reopens it tomorrow, the items should still be there). This can be handled either through local-storage or through the shopify-buy JS library.
 - **Product search** can be done client-side if the SKU count is small enough to store all products in a global state. Alternatively, it can be handled through the e-commerce provider’s search features, or if those aren’t robust enough, a third-party search provider like Algolia.
 - **Surfacing price adjustments** like tax, shipping, discounts/promos to the user while browsing the site. Different e-commerce solutions provide different levels of API access to these objects.
 - **Handling checkout.** In order to comply with PCI regulations around storing credit card information, e-commerce providers typically exert strong control over the "buy" or "checkout" experience. Shopify requires all checkout flows using their platform to use their hosted checkout pages, though it's common to wrap them in a subdomain of the main site (eg the Gatsby/Shopify site [strivectin.com](strivectin.com] wraps a `myshopify.com` URL under a `shop.strivectin.com` URL for checkout).