fix: cycle detection returns duplicate closing node in reported cycle…

[Adityakk9031]

Summary

• visitCycleNode appended node to the returned cycle slice even though node is already present in path at existingIndex — the cycle check fires before the node is pushed onto path, so path.slice(existingIndex) already contains the full cycle
• This caused CycleDetectionResult.cycle to always include the starting node twice (e.g. ['A','B','C','A'] instead of ['A','B','C'])
• has_cycle detection was unaffected (non-empty array still signals a cycle), but the cycle payload fed to Forme's acyclicity postcondition was incorrect

Change

// before
return [...path.slice(existingIndex), node];

// after
return path.slice(existingIndex);

[Adityakk9031]

@josemontesdeoca have a look please

[josemontesdeoca]

@Adityakk9031 thank you for tracing the visitCycleNode path carefully and for separating the cycle payload from the unchanged has_cycle behavior. I’m also sorry that this first pull request to the repository waited so long.

The tests at the revision this PR is based on intentionally treat the cycle array as a closed walk: they expect shapes like [A, B, C, A] and [A, B, A], where the repeated starting node records the closing edge. Removing that entry would make the implementation disagree with the existing contract.

Because of that, I don’t think this behavior change should merge as written. If you found a consumer or documented contract that requires the unique-node representation, please point me to it and I’ll reconsider that evidence. I’d like to leave a short opportunity for your reply before I make the close decision. Your investigation still surfaced a real clarity problem: the closed-walk representation should be easier to discover in the documentation.

Separately, if you’d ever like to tell me about the OpenProse use case you were exploring when you found this, I’d be interested to hear it. That is optional and has no effect on this review.

[Adityakk9031]

Thanks @josemontesdeoca for the clear explanation! That makes complete sense — I see now that the repeating closing node [A, B, C, A] is intentional to represent a closed walk and explicitly record the closing edge.

I've updated this PR to preserve the closed walk behavior and added explicit JSDoc comments to CycleDetectionResult and detectReceiptCycles so the closed-walk contract [A, B, ..., A] is clear for future contributors.