docs: remove network-specific addresses from frontend guide

[liobrasil]

Summary

• remove hardcoded network-specific addresses from FRONTEND_INTEGRATION.md
• switch EVM and FCL examples to config-driven network selection and aliases
• keep the refund guidance while removing the network-bound PYUSD0 example

Testing

• not run (docs only)

[claude]

getCadenceConfig and getCurrentNetworkKey are never defined.

Both helper functions appear in every code example but are not defined, imported, or documented anywhere in this guide or in the repo. A developer following this guide has no way to implement them.

At a minimum the guide needs to show the expected shape of getCadenceConfig's return value and where it comes from. Something like:

// Example – implement this for your app
function getCurrentNetworkKey(): "mainnet" | "testnet" {
  // return the active network
}

interface CadenceConfig {
  accessNodeApi: string;       // e.g. "https://rest-testnet.onflow.org"
  flowNetwork: string;         // e.g. "testnet"
  flowYieldVaultsEVM: string;  // Cadence address of FlowYieldVaultsEVM contract
  flowYieldVaults: string;     // Cadence address of FlowYieldVaults contract
}

function getCadenceConfig(network: "mainnet" | "testnet"): CadenceConfig {
  // return per-network values
}

Without this, the "network-agnostic" refactor leaves the guide less usable than the hardcoded version it replaced.

[claude]

Wrong address used for managerAddress — balance queries will return nil/0.0 at runtime.

cadenceConfig.flowYieldVaults is the address of the FlowYieldVaults contract, but managerAddress must be the account that holds the YieldVaultManager capability — which is the FlowYieldVaultsEVM worker account (cadenceConfig.flowYieldVaultsEVM).

The check_worker_status.cdc and check_yieldvaultmanager_status.cdc scripts confirm that the YieldVaultManager is stored and published by the FlowYieldVaultsEVM account, not the FlowYieldVaults contract account. Passing the wrong address means capabilities.borrow(...) will always return nil, so every balance and details query silently returns nil/0.0.

The same bug appears on the three call-sites in this file (lines ~407, ~440, ~464). All three should be:

Suggested change

	const balance = await fcl.query({
	cadence: GET_YIELDVAULT_BALANCE,
	args: (arg, t) => [
	arg(FLOW_YIELD_VAULTS_ADDRESS, t.Address),
	arg(cadenceConfig.flowYieldVaults, t.Address),
	arg(yieldVaultId.toString(), t.UInt64),
	],
	});
	arg(cadenceConfig.flowYieldVaultsEVM, t.Address),

This bug pre-existed the PR (the old code used the same wrong FLOW_YIELD_VAULTS_ADDRESS), but since this PR touches every one of these lines it's the right time to fix it.

[claude]

Review Summary

Documentation-only PR. Two concrete issues found.

1. getCadenceConfig / getCurrentNetworkKey are undefined (blocking)

The refactor introduces two helper functions that appear in every code snippet but are never defined, imported, or explained anywhere in the guide or repo. The old hardcoded version was self-contained; the new version isn't. Developers can't follow the guide without knowing the shape of CadenceConfig and where the functions come from. See inline comment at line 25.

2. Wrong address for managerAddress in FCL balance/details queries (correctness)

GET_YIELDVAULT_BALANCE, GET_YIELDVAULT_DETAILS, and getUserPositions all pass cadenceConfig.flowYieldVaults (the FlowYieldVaults contract address) as managerAddress. The YieldVaultManager capability is published by the FlowYieldVaultsEVM worker account, not the FlowYieldVaults contract account. Passing the wrong address causes capabilities.borrow(...) to return nil, so every balance and details query silently returns nil/0.0 at runtime. This pre-exists the PR but all three affected lines are touched here — good moment to fix. See inline comment spanning lines 404–410.

What looks good

• FCL alias pattern (0xFlowYieldVaultsEVM, 0xFlowYieldVaults) is correct and idiomatic.
• New refund behavior section (lines 584–589) accurately describes the contract: refunds aggregate per user+token, claimRefund(tokenAddress) is the right call, and the "show CTA when balance > 0 regardless of request row state" guidance matches the pull-pattern in the contract.