🔁 Refresh channel accounts section

[JFWooten4]

from #723

⚠️ Relies on images from #2400

[Copilot]

Pull request overview

Expands the channel accounts guide with architecture, security, throughput, and multi-SDK implementation guidance.

Changes:

• Adds diagrams and channel-account concepts.
• Adds Python, JavaScript, Java, and Go examples.
• Documents rotation, fees, capacity, and operational considerations.

Recommendation: NEEDS-CHANGES — fix the non-runnable SDK examples, unsafe rotation logic, and inaccurate fee/capacity guidance.

Comments suppressed due to low confidence (8)

docs/build/guides/transactions/channel-accounts.mdx:129

• StellarSdk is not defined by the destructuring import. Use the imported Operation symbol here as well.

  transaction2.addOperation(StellarSdk.Operation.payment({

docs/build/guides/transactions/channel-accounts.mdx:475

• This second Java tab also uses the removed Transaction.Builder and new PaymentOperation.Builder(...) APIs, so it cannot compile with Java SDK 4.x. Migrate it to TransactionBuilder and PaymentOperation.builder() before publishing the refreshed guide.

  Transaction.Builder transactionBuilder = new Transaction.Builder(channelAccount, Network.TESTNET)
    .setBaseFee(Transaction.MIN_BASE_FEE);

  for (String recipient : allRecipients.get(i)) {
    transactionBuilder.addOperation(
      new PaymentOperation.Builder(recipient, AssetTypeNative.INSTANCE, "10")
        .setSourceAccount(primaryKeypair.getAccountId())

docs/build/guides/transactions/channel-accounts.mdx:714

• This JavaScript loop has the same rotation deadlock: once every channel is active, no code marks one available until after this loop exits, which cannot happen while recipients remain. Process and await each wave before assigning another batch.

while (recipientIndex < allRecipients.length) {
  for (const channelData of channelAccountsTracker) {
    if (recipientIndex >= allRecipients.length) break;
    if (channelData.state === "available") {
      channelData.state = "active";

docs/build/guides/transactions/channel-accounts.mdx:878

• This Go loop also deadlocks after one batch per channel because channel states are reset only in the submission loop below. If recipients remain after every channel becomes active, neither index nor state can change.

	for recipientIndex < len(allRecipients) {
		for _, channelData := range channelAccountsTracker {
			if recipientIndex >= len(allRecipients) {
				break
			}
			if channelData["state"] == "available" {

docs/build/guides/transactions/channel-accounts.mdx:783

• The Java rotation loop cannot handle more than one batch per channel: after all channels become active, no state is reset until the later submission loop, so this while loop has no way to make progress. Submit and confirm each wave before continuing allocation.

  while (recipientIndex < allRecipients.length) {
    for (ChannelAccount channelData : channelAccountsTracker) {
      if (recipientIndex >= allRecipients.length) break;
      if (channelData.state.equals("available")) {
        channelData.state = "active";

docs/build/guides/transactions/channel-accounts.mdx:759

• Even after awaiting submission, this unconditional release is unsafe on rejection or an unknown transport outcome: the local account sequence was advanced when the transaction was built, but the network may not have consumed it. Query/reload the channel account and reconcile the transaction before setting it available.

  } finally {
    channelData.state = "available";

docs/build/guides/transactions/channel-accounts.mdx:823

• This releases the Java channel even when submission failed or its outcome is unknown. Because transaction construction advances the local account sequence, the next build can use a sequence that does not match the network; reconcile/reload the account before making it available.

    } finally {
        txBundle.channelData.state = "available";

docs/build/guides/transactions/channel-accounts.mdx:943

• This marks the channel available after both success and failure without reconciling its sequence. When submission fails or times out, IncrementSequenceNum may have advanced only the local account, so reusing it can produce a sequence gap. Reload/verify the network account before release on non-confirmed outcomes.

		output.channelData["state"] = "available"