[Bug]: Decoder does not restore the parent value after decoding a child #3

Describe the bug

In XCJSON.Decoder.decode(_:pathComponent:), oldCurrentValue captures the incoming child value rather than the decoder's existing currentValue:

let oldCurrentValue = value
defer {
    currentValue = oldCurrentValue
}

As a result, after decoding a child, currentPath is restored to the parent path, but currentValue still refers to the child.

Observed on main at c132630aabf40f6d6c3f7bb004595d2e5a28ea42.

Steps to reproduce

The following can be added to the existing library test target, which has access to the package-scoped decoder:

import Foundation
import Testing
import XcodeProjectFormat

private struct ParentValueProbe: XCJSON.Decodable {
    init(with coder: XCJSON.Decoder) throws {
        let container = try coder.openKeyedContainer()
        let _: String = try container.decode("name")

        #expect(coder.currentNodeType == .object)
        _ = try coder.openKeyedContainer()
    }
}

@Test func restoresParentValueAfterDecodingChild() throws {
    let _: ParentValueProbe = try XCJSON.Decoder.decode(
        data: Data(#"{"name":"App"}"#.utf8)
    )
}

Save the test as Sources/Tests/DecoderStateTests.swift, then run from the repository root:

swift test --filter restoresParentValueAfterDecodingChild

Expected behavior

If the decoder is intended to restore its parent context after decoding a child, currentNodeType should remain .object, and reopening the parent's keyed container should succeed.

Actual behavior

After decoding name, the current node is a string. Reopening the keyed container throws:

Expected an instance of dictionary but an instance string was specified

Stack trace

N/A — this produces an assertion failure and a thrown error, not a crash.

Environment

• Version: main at c132630
• OS: macOS 26.6.2 (25G83), Apple silicon (arm64)
• Swift version: Apple Swift 6.4 (swiftlang-6.4.0.34.1)
• Xcode: 27.2 beta (27B5019j)

Additional context

I reproduced this with a standalone probe against the library, but have not found an existing public Project decoding case affected by it. Existing decoding implementations that retain their original container may not encounter the issue.

Is restoring the parent value the intended behavior? If so, changing the saved value to currentValue appears to address it. I would be happy to submit a focused fix with regression tests covering restoration after both successful and throwing child decodes.