Bump version to v1.2.0: Enable smart reuse via currentExecution getter to expose the active task's promise

Author: ori88c

README.md

@@ -24,6 +24,7 @@ If your use case involves keyed tasks - where you need to ensure the mutually ex
 - __Mutual Exclusiveness :lock:__: Ensures the mutually exclusive execution of asynchronous tasks, either to prevent potential race conditions caused by tasks spanning across multiple event-loop iterations, or for performance optimization.
 - __Graceful Teardown :hourglass_flowing_sand:__: Await the completion of all currently pending and executing tasks using the `waitForAllExistingTasksToComplete` method. Example use cases include application shutdowns (e.g., `onModuleDestroy` in Nest.js applications) or maintaining a clear state between unit-tests.
 - __Suitable for "Check and Abort" scenarios :see_no_evil:__: The `isAvailable` getter indicator enables to skip or abort operations if the lock is currently held by another task.
+- __Smart Reuse :recycle:__: In scenarios where launching a duplicate task would be wasteful (e.g., refreshing a shared resource or cache), consumers can **await the ongoing execution instead of scheduling a new one**. This is enabled via the `currentExecution` getter, which exposes the currently executing task's promise, if one is active.
 - __Backpressure Metric :bar_chart:__: The `pendingTasksCount` getter provides a real-time metric indicating the current backpressure from tasks waiting for the lock to become available. Users can leverage this data to make informed decisions, such as throttling, load balancing, or managing system load. Additionally, this metric can aid in **internal resource management** within a containerized environment. If multiple locks exist - each tied to a unique key - a backpressure value of 0 may indicate that a lock is no longer needed and can be removed temporarily to optimize resource usage.
 - __High Efficiency :gear:__: Leverages the Node.js microtasks queue to serve tasks in FIFO order, eliminating the need for manually managing an explicit queue of pending tasks.
 - __Comprehensive documentation :books:__: The class is thoroughly documented, enabling IDEs to provide helpful tooltips that enhance the coding experience.
@@ -65,6 +66,7 @@ If needed, refer to the code documentation for a more comprehensive description
 The `ZeroOverheadLock` class provides the following getter methods to reflect the current lock's state:
 
 * __isAvailable__: Indicates whether the lock is currently available to immediately begin executing a new task. This property is particularly useful in "check and abort" scenarios, where an operation should be **skipped or aborted** if the lock is currently held by another task.
+* __currentExecution__: Exposes the currently executing task's promise, if one is active. This is useful in scenarios where launching a duplicate task would be wasteful - consumers can simply **await the ongoing execution instead**. This feature enhances the lock’s versatility and supports advanced usage patterns.
 * __pendingTasksCount__: Returns the number of tasks that are currently pending execution due to the lock being held. These tasks are waiting for the lock to become available before they can proceed.
 
 ## Use Case Example: Aggregating Intrusion Detection Event Logs :shield:<a id="first-use-case-example"></a>

dist/zero-overhead-promise-lock.d.ts

@@ -49,6 +49,7 @@ export type AsyncTask<T> = () => Promise<T>;
  */
 export declare class ZeroOverheadLock<T> {
     private _pendingTasksCount;
+    private _currentExecution?;
     /**
      * Availability indicator:
      * A pending `_waitForAvailability` promise signifies that the lock is currently held.
@@ -69,6 +70,19 @@ export declare class ZeroOverheadLock<T> {
      * @returns `true` if no task is currently executing; otherwise, `false`.
      */
     get isAvailable(): boolean;
+    /**
+     * currentExecution
+     *
+     * Exposes the currently executing task's promise, if one is active.
+     *
+     * ### Smart Reuse
+     * This property is useful in scenarios where launching a duplicate task is wasteful.
+     * Instead of scheduling a new task, consumers can await the ongoing execution to avoid
+     * redundant operations.
+     *
+     * @returns The currently executing task’s promise, or `undefined` if the lock is available.
+     */
+    get currentExecution(): Promise<T> | undefined;
     /**
      * pendingTasksCount
      *