Considering making the Completion interface extend AutoCloseable

Nobody has claimed this yet.

## Background and Intention
When using asynchronous processing completion, if a completion leak occurs, the system will be unable to consume furthur records which is quite dangerous. Therefore, avoiding completion leaks during development is a critical issue that requires attention.

However, in the context of collaboration and maintenance, as the complexity of the codebase increases and maintainers change over time, the likelihood of developers overlooking completion leaks also rises (e.g., complete being called across different locations in the call chain). I am considering whether there is a way to increase developers' awareness of completion leaks or to automatically check them.

## Considerations
Perhaps one of the most effective approaches would be for developers to perform AST-based code analysis on their respective projects and integrate it into the CI pipeline. However, this is not something Decaton project can guarantee, and due to the cost, it is often not carried out.

Therefore, I am considering whether `Completion` could be annotated at the code level as something that must be completed, or whether it could be automatically completed at the appropriate time (though I haven't thought of a reasonable implementation for this).

Eventually, one idea I have is for `Completion` to extend the `AutoCloseable` interface. While this doesn't have any practical function, it would allow most developers' IDEs to detect the implementation of the `AutoCloseable` interface through their inspector tools, triggering warnings and serving as a pre-warning stuff.

I’d like to hear your thoughts on this. Thank you!
> While this doesn't have any practical function ->
> - In sync complete scenarios, after the `process` method returns, the completion will be completed by decaton, so there is no need to control the completion process
> - In async complete scenarios, the completion is often completed during a callback, and completing it prematurely can cause issues.

The issue does not name any files, tests, or entry points. Start by locating the Completion interface and tracing its synchronous and asynchronous lifecycle; done would require a decided, documented scope for whether and how AutoCloseable support should be added.

Written by the indexing model from the issue text.