…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```

…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```

…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```

…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```

…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```

…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```

…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```

…ree semantics

## Context

The Plonky3 migration includes an updated PartialSmt implementation in miden-crypto
that changes the semantics of "tracked" keys in empty trees.

## Semantic Change

In the new PartialSmt implementation, a key is considered "tracked" if either:
1. Its merkle path was explicitly added via add_path/add_proof, OR
2. The path from the leaf to the root goes through empty subtrees that are
   provably empty (they equal the empty subtree root hash).

Critically, in a COMPLETELY EMPTY tree (root == EMPTY_ROOT), ALL keys satisfy
condition #2 and are therefore implicitly tracked. This is correct cryptographic
behavior: in an empty tree, all leaves are provably empty via zero hash
computations, so there's no need to explicitly track them.

## Test Update

The test `upsert_state_commitments_fails_on_untracked_key` was using
`PartialAccountTree::default()` which creates an empty tree with EMPTY_ROOT.
Under the new semantics, all keys are implicitly tracked in this tree, so
inserting an "untracked" key would succeed rather than fail.

The fix: Initialize the partial tree with a non-empty root so that keys are
NOT implicitly tracked, allowing us to properly test the UntrackedAccountId
error path.

## Related Code

See miden-crypto/src/merkle/smt/partial/mod.rs:368-370:
```rust
// Empty tree - all leaves implicitly trackable
if self.root == Self::EMPTY_ROOT {
    return Some(SmtLeaf::new_empty(leaf_index));
}
```