fix(core): make missing checkpoint threadId observable and optionally strict

[Carl-Zhou-CN]

Contributing to ARGI: when RunnableConfig omits threadId, checkpoint savers now log a one-shot warning instead of silently sharing the "$default" namespace, and an opt-in strict policy (argi.checkpoint.requireExplicitThreadId=true or CheckpointThreadIdPolicy.setRequireExplicitThreadId(true)) makes checkpoint operations fail fast until an explicit threadId is provided; includes offline regression tests for MemorySaver and VersionedMemoryCheckpointSaver, README documentation of the shared $default semantics, and a lint-script skip for the machine-local .awr runtime directory. Fixes #154

[Aias00]

Review: fix(core): make missing checkpoint threadId observable and optionally strict (#154)

Verdict: APPROVE

This is a clean, well-scoped fix for a real cross-caller data-sharing / observability gap (issue #154): an omitted threadId silently fell back to the shared $default bucket, so unrelated callers on the same saver instance could read each other's checkpoints.

What's good

• checkpointThreadId is the single chokepoint and cannot be bypassed. I verified every saver implementation routes through it: MemorySaver, RedisSaver, MongoSaver, FileSystemSaver, VersionedMemorySaver, and MemoryLeasedCheckpointSaver call it directly; H2Saver/MysqlSaver/OracleSaver/PostgresSaver inherit it via AbstractJdbcCheckpointSaver (none override get/put/list). So the warning + strict IllegalArgumentException fire uniformly on every saver operation.
• One-shot warning (AtomicBoolean, never floods logs) plus a clear strict-mode error that names the argi.checkpoint.requireExplicitThreadId property.
• Solid regression suite: shared-bucket reproduction, strict rejects get/put/list/checkpointThreadId, strict accepts an explicit id, per-identity scoping, strict-rejects-even-with-metadata, cross-saver. @AfterEach restores the policy for test isolation.
• README + javadoc document the $default sharing semantics and the strict switch.

Non-blocking nits

1. Javadoc on setRequireExplicitThreadId(false) says it "restores the startup default derived from the property," but the implementation sets the field to the passed value unconditionally (does not re-read the property). Minor doc/behavior mismatch — the test's restore helper correctly re-reads it.
2. requireExplicitThreadId is a JVM-global mutable static. Fine for tests, but for production prefer the system-property form (immutable at startup) so one caller can't flip it process-wide.
3. The PR body mentions "a lint-script skip for the machine-local .awr runtime directory," but that change is not in the diff (only 4 checkpoint-related files). Confirm it landed in another PR or drop it from the description.
4. migrateLegacyThread still computes legacyThreadId via config.threadId().orElse(THREAD_ID_DEFAULT) directly before validating via checkpointThreadId; a legacy config with no threadId won't trigger the new warning on that path. Minor / intended (migration path).

No CI checks were reported on the branch at review time; the included offline suite is sufficient.