Return an error when CbfNode is started twice

[j-kon]

Description

Closes #1084.

Changes the exported CbfNode::run() method to return Result<(), CbfError> and adds the binding-visible NodeAlreadyStarted error. The first caller starts the node; later or racing callers receive the typed error instead of silently succeeding.

Regression coverage exercises consumed, sequential, and concurrent calls in Rust. The Android binding test also verifies the generated CbfException.NodeAlreadyStarted exception.

Notes to the reviewers

This intentionally covers only duplicate lifecycle calls. Reporting Tokio runtime construction or Kyoto node-exit failures remains tracked separately in #1089.

Binding verification completed with Kotlin generation plus :lib:compileDebugAndroidTestKotlin, and Swift generation plus swift test.

Documentation

• Other: lifecycle semantics and acceptance criteria are defined in Make CbfNode::run return an error when called more than once in 4.0 #1084

Changelog

Breaking API change: CbfNode.run() now throws/returns an error. Please apply changelog: breaking.

Checklists

All Submissions:

• I have signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing
• I have added exactly one changelog:* label
• I have linked the relevant upstream docs or specs above

Bugfixes:

• This pull request breaks the existing API
• I have added tests to reproduce the issue which are now passing
• I am linking the issue being fixed by this PR

[j-kon]

@reez, could you please review this API-breaking fix for #1084 when you have a chance?

[henrypeters]

Review of PR #1092: Return an error when CbfNode is started twice

Suggestions for Improvement

- Add Swift Binding Test

Currently only Android/Kotlin tests the generated exception. Consider adding equivalent Swift test coverage to ensure consistency across all bindings.

- Documentation: Recovery Strategies

Add guidance in docstring about error handling patterns for users. Include examples of how to handle the error gracefully.

- Consider Adding State Inspection Method

To help consumers avoid race conditions, consider adding (as a follow-up):

pub fn is_running(&self) -> bool {
    self.node.lock().unwrap().is_none()
}

- Changelog Label

The PR description mentions 'Please apply changelog: breaking' but notes the label wasn't added. Ensure this is applied before merge - this is required.

- Comment in Concurrent Test

The concurrent_run_calls_allow_one_caller test is excellent but could use inline comments explaining the barrier pattern for clarity.

[j-kon]

@henrypeters Thanks for the review. I checked each suggestion against the current API:

• CbfClient::is_running() already reports the Kyoto requester runtime state. A CbfNode::is_running() implemented as node.is_none() would only report that the one-shot node was consumed; it would remain true after the detached node thread exits, so I have not added that misleading API.
• The generated Swift binding exposes run() throws, and the XCFramework build plus Swift test suite compile that API. The Android instrumentation test provides the binding-level runtime regression; this repository currently has no Swift CBF fixture, so adding one would expand the scope beyond this fix.
• The run() docs already state the one-shot lifecycle and typed NodeAlreadyStarted failure. The barrier test directly coordinates the two competing callers, so I kept it focused rather than adding comments that repeat the code.

The branch is now rebased onto current master. Rust format/clippy/tests, Android test compilation, and Swift XCFramework/tests all pass locally.

@thunderbiscuit, could you apply changelog: breaking and review when convenient?