docs: onchain ERC-8021 attribution for direct smart-contract integrators

User Story

As a developer integrating via direct Gateway smart-contract calls, I want clear documentation on how to attribute my createOrder transactions onchain with an ERC-8021 data suffix derived from my API key ID, so my orders link to my sender profile and webhooks without (or in addition to) putting apiKey in encrypted recipient metadata.

Acceptance Criteria

1. GIVEN a reader of the Smart Contract Interaction guide
   WHEN they follow the new onchain attribution section
   THEN they can encode an ERC-8021 schema-0 suffix from their API key UUID (dashes stripped) and append it to outer createOrder calldata before signing / gas estimation

2. GIVEN the same guide's existing metadata.apiKey instructions
   WHEN the docs are updated
   THEN backward compatibility is explicit: metadata.apiKey still works; onchain suffix is preferred for new EVM integrations; when both are present the aggregator prefers onchain

3. GIVEN Base vs other EVM chains
   WHEN the docs explain codes
   THEN they clarify that bc_julg9gbq is Paycrest/noblocks' Base Builder Code (not for arbitrary senders to claim) and sender attribution uses the API key ID code

4. GIVEN Starknet / Tron (or other non–ERC-8021 paths)
   WHEN the docs discuss attribution
   THEN they state those networks continue to use metadata.apiKey only

5. GIVEN wallet / AA constraints
   WHEN the docs cover where the suffix must live
   THEN they require the suffix on outer tx.data / userOp.callData (not buried in an inner call), consistent with aggregator/noblocks implementation notes

6. GIVEN cross-links
   WHEN docs ship
   THEN Smart Contract Interaction (and optionally Sender API / changelog) links to ERC-8021 / Base Builder Codes references; embed host attribution is documented as a noblocks widget concern (not required for direct SC senders)

Tech Details

• Primary surface: docs/implementation-guides/smart-contract-interaction.mdx (Data Encryption / createOrder sections).
• Add a dedicated Onchain attribution (ERC-8021) section with:
  • Why (sender linkage / webhooks without putting API key ID only in encrypted blob)
  • How to get the API key ID from the dashboard
  • Encode helper example (JS at minimum; align with Viem examples already in the guide)
  • Multi-code note for Base only if co-branding with Paycrest — default sender example is API key ID alone
  • Deprecation/migration note for metadata.apiKey
• Optional: short changelog entry under docs/resources/changelog.mdx when aggregator support lands.
• Coordinate copy with aggregator + noblocks tickets so examples match the shipped suffix format.

Notes/Assumptions

• Docs ticket can be drafted against the agreed format before aggregator ships, but should not claim production support until the indexer resolves onchain codes.
• API key ID is public attribution material; API secret remains offchain for webhooks/REST only.
• Refs: https://blog.base.dev/builder-codes-and-erc-8021-fixing-onchain-attribution · https://www.erc8021.com/ · https://eip.tools/eip/8021

Start with docs/implementation-guides/smart-contract-interaction.mdx, especially the Data Encryption and createOrder sections, and review the linked ERC-8021, Base Builder Codes, aggregator, and noblocks references. Add the onchain attribution guidance, JavaScript encoding example, network and wallet constraints, migration notes, and cross-links described in the acceptance criteria. Done means the guide clearly distinguishes API-key attribution from Base Builder Codes, preserves metadata.apiKey guidance, and avoids claiming production support before aggregator support lands.