feat: add a dedicated Storefront GraphQL client

[0xtlt]

Summary

• add a dedicated ShopifyStorefront client with tokenless, public-token, and private-token authentication
• forward trusted buyer IPs per request through StorefrontRequestContext
• share GraphQL transport and response handling internally between Admin and Storefront clients
• use the Storefront GraphQL endpoint and the correct Shopify headers for each authentication mode
• keep Admin-only methods on Shopify, so invalid Admin/Storefront combinations fail at compile time

Why

The client currently hardcodes the Admin GraphQL endpoint, so it cannot be used for custom storefront workloads. Storefront requests need a different URL and different authentication headers.

Private-token requests made by a server on behalf of buyer traffic must also forward Shopify-Storefront-Buyer-IP. Keeping that value in a per-request context prevents buyer IPs from leaking across concurrent requests. Static builds and other non-buyer traffic can continue to use the regular GraphQL methods.

A separate public type keeps invalid Admin/Storefront combinations out of the API: callers get a compile-time error instead of a runtime guard when attempting an Admin-only operation on a Storefront client.

Closes #22.

Developer impact

Existing Shopify, Shopify::new, and ShopifyConfig usage remains unchanged. Storefront clients opt in through ShopifyStorefront::new, StorefrontAuth, and StorefrontConfig. Buyer-originated private-token calls use the corresponding *_with_context method.

Validation

• cargo test --all-features
• cargo test --no-default-features
• HTTP-level tests for tokenless, public-token, private-token, auth replacement, buyer IPv4/IPv6, and graphql-client
• cargo clippy --all-targets --all-features -- -D warnings
• cargo fmt -- --check
• RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --document-private-items --all-features
• independent Shopify-docs and code-quality re-reviews: approved with no actionable findings