docs: split miscoupled private-PDA test docs and clean phrasing

Addresses the following review comments:

- "Isn't two_mask_3_claims_under_same_seed_are_rejected already checking
  that there's a mechanism protecting against this exploit scenario?"
  The doc block at nssa/src/state.rs:2488-2504 mixes three paragraphs,
  one about reuse, one TODO about wallet side input, one exploit pin,
  all attached to two_mask_3_claims_under_same_seed_are_rejected. The
  reuse test below it had no doc at all. I split as follows: the
  exploit-pin paragraph stays on two_mask_3_claims_..., the reuse
  paragraph moves to a fresh docstring on
  mask_3_reuse_across_txs_currently_unsupported.

- "I don't understand this. I think this should fail because ... the
  input pre_state which is marked with is_authorized=true will make
  things fail."
  The reuse test's new docstring cites the actual reject site, the
  post-loop private_pda_bound_positions assertion in
  privacy_preserving_circuit.rs:185-192. At top level the Entry::Vacant
  arm accepts is_authorized=true unconditionally, the rejection comes
  from the bound-positions check firing because noop emits no Claim::Pda
  and there is no caller ChainedCall.pda_seeds.

- "let's dont have this TODO as part of the doc"
  The block is moved out into regular // comments immediately above
  mask_3_reuse_across_txs_currently_unsupported.

- "let's not add implementation details to docs"
  In caller_pda_seeds_authorize_mask_3_private_pda_for_callee's
  docstring, I dropped the parenthetical "(Occupied branch)" and the
  trailing sentence about which validate_and_sync_states code path gets
  exercised.

- "what does \`Claim::Pda(seed)\` / \`pda_seeds\` mean?"
  I rewrote the pda_family_binding docstring at
  privacy_preserving_circuit.rs:33-39: replaced the ambiguous
  "Claim::PrivatePda and ChainedCall's private seeds into plain
  Claim::Pda(seed) / pda_seeds" phrase with "a Claim::Pda(seed) in a
  program's post_state or a caller's ChainedCall.pda_seeds entry".

- Suggestion on nssa/src/validated_state_diff.rs:226 rewriting
  "The public-execution path only sees mask-0 accounts" to
  "The public-execution path only sees public accounts".
  Applied: "The public-execution path only sees public accounts".

- Clarification requested on the private_pda_bound_positions field:
  I expanded the docstring at privacy_preserving_circuit.rs:26-31 to
  state that binding is an idempotent property, not an event, and to
  enumerate the two proof paths that populate it (a Claim::Pda on a
  mask-3 pre_state, or a caller's pda_seeds matching under the private
  derivation).

program_methods/guest/src/bin/privacy_preserving_circuit.rs

@@ -23,20 +23,26 @@ struct ExecutionState {
     post_states: HashMap<AccountId, Account>,
     block_validity_window: BlockValidityWindow,
     timestamp_validity_window: TimestampValidityWindow,
-    /// Positions (in `pre_states`) of mask-3 accounts whose wallet-supplied npk has been bound
-    /// to their `AccountId` via a proven `private_pda_account_id(program_id, seed, npk)` check.
-    /// The binding happens when the circuit validates a `Claim::Pda(seed)` on that `pre_state`,
-    /// or when it authorizes that `pre_state` via a caller's `ChainedCall.pda_seeds`. After the
-    /// main loop, every mask-3 position must appear in this set; otherwise the npk is unbound
-    /// and the circuit rejects.
+    /// Positions (in `pre_states`) of mask-3 accounts whose supplied npk has been bound to
+    /// their `AccountId` via a proven `private_pda_account_id(program_id, seed, npk)` check.
+    /// Two proof paths populate this set:
+    ///   1. A `Claim::Pda(seed)` in a program's post_state on that `pre_state`.
+    ///   2. A caller's `ChainedCall.pda_seeds` entry matching that `pre_state` under the
+    ///      private derivation.
+    /// Binding is an idempotent property, not an event: the same position can legitimately be
+    /// bound through both paths in the same tx (e.g. a program claims a private PDA and then
+    /// delegates it to a callee), and the set uses `contains`, not `assert!(insert)`. After
+    /// the main loop, every mask-3 position must appear in this set; otherwise the npk is
+    /// unbound and the circuit rejects.
     mask3_bound_positions: HashSet<usize>,
     /// Across the whole transaction, each `(program_id, seed)` pair may resolve to at most one
-    /// `AccountId`. A seed under a program can derive a family of accounts (one public PDA and
-    /// one private PDA per distinct npk), and unifying `Claim::PrivatePda` and `ChainedCall`'s
-    /// private seeds into plain `Claim::Pda(seed)` / `pda_seeds` would otherwise let a single
-    /// `pda_seeds: [S]` in a chained call authorize multiple family members at once. We record
-    /// every claim and caller-authorization resolution here and reject any mismatch, making the
-    /// rule: one `(program, seed)` → one account per tx.
+    /// `AccountId`. A seed under a program can derive a family of accounts, one public PDA and
+    /// one private PDA per distinct npk. Without this check, a single `pda_seeds: [S]` entry in
+    /// a chained call could authorize multiple family members at once (different npks under the
+    /// same seed) and let a callee mix balances across them. Every claim and every
+    /// caller-authorization resolution is recorded here, either as a new `(program, seed)` →
+    /// `AccountId` entry or as an equality check against the existing one, making the rule: one
+    /// `(program, seed)` → one account per tx.
     pda_family_binding: HashMap<(ProgramId, PdaSeed), AccountId>,
 }