Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@promising/promising_function.py`:
- Around line 155-160: Replace the private asyncio hook usage by using
inspect.markcoroutinefunction() on Python 3.12+ and fall back to the existing
asyncio.coroutines._is_coroutine for older Pythons: update the assignment of
_is_coroutine in promising_function.py so that if sys.version_info >= (3,12) you
call inspect.markcoroutinefunction() to mark the Promising function type,
otherwise keep the current asyncio.coroutines._is_coroutine fallback (keep
reference to the existing symbol _is_coroutine and the current logic that relies
on asyncio.coroutines._is_coroutine for 3.11).

---

Outside diff comments:
In `@promising/promising_context.py`:
- Around line 753-761: The TODO notes that _call_soon_threadsafe currently
raises SyncUsageError with a message mentioning synchronous operations, which is
inaccurate; change the raised exception in _call_soon_threadsafe from
SyncUsageError to a more general/appropriate error (e.g.,
EventLoopNotRunningError or ContextUsageError) and update the message to not
reference "synchronous operation" (suggest: "The event loop associated with this
{self.__class__.__name__} is not running"); add or update the custom exception
class (if needed) and keep the TODO comment or open a follow-up issue to track
any broader refactor of error taxonomy so all callers reflect the new semantics.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@promising/__init__.py`:
- Around line 44-49: Add a disableable defensive check where synchronous promise
call depth is tracked (the code path that schedules work into the
ThreadPoolExecutor and the Promise/PromiseExecutor logic) to detect when current
synchronous call depth >= executor.max_workers and raise a clear, specific
exception (e.g., SynchronousCallDepthExceededError or ThreadPoolExhaustionError)
instead of deadlocking; make this behavior configurable via a toggle (e.g., a
module-level flag or env var like PROMISING_DISABLE_DEPTH_CHECK or an optional
parameter on Promise/PromiseExecutor with default enabled) so callers can opt
out, and update/add unit tests to assert the exception is raised when depth
reaches max_workers and that the toggle disables the check.

In `@promising/promise.py`:
- Around line 109-113: Create two tracked GitHub issues for the P1 TODOs
referenced in promising/promise.py: one for "support async generator interface"
and one for "memory leak prevention for long sequences/streams". Each issue
should include a clear problem statement, proposed approaches (e.g., async
iterator protocol support, backpressure/eviction strategies or weak buffering,
explicit APIs for one-pass streams), acceptance criteria, and labels (e.g., P1,
architecture). Then update the TODO comments in promising/promise.py to include
the created issue numbers (e.g., TODO #[issue-number]) and a short note pointing
to the issue for design decisions and progress tracking.