feat(cache-manager)!: lock get_or_set() by default

[allen0099]

Closes #280.

Changes

• CacheManager(lock=...) defaults to True, so the manager AppCache creates locks too. Concurrent misses of one key run factory once; the other callers wait for its result.
• The 0.3.9 FutureWarning for an unset lock is removed.
• CacheManager(lock=None) raises TypeError. get_or_set(lock=None) still inherits the manager's setting.
• Docs:
  • APP_CACHE.md replaces "The default changes in 0.4.0" with a Cost section. It lists backend round trips for a hit (1), an uncontended miss (2 → 6 on Redis/Memcached) and each waiting caller (2 per poll).
  • MIGRATING_0_4.md#get-or-set-lock covers the new default, the TypeError, waiting latency (lock_ttl / wait_timeout) and the lock:<prefix><key> key.
  • README, zh-TW index and examples/app_cache.py drop the now-redundant lock=True.
  • All doc changes are in both languages.

Tests

• The default-path tests now assert that the lock is used.
• The live stampede test across memory, Redis and Memcached now relies on the default instead of passing lock=True.
• The shared cache_manager fixture and two single-backend tests no longer pin lock=False.
• Mutation checks:
  • Reverting the default to False fails 6 tests, including the Redis and Memcached runs.
  • Accepting lock=None fails test_stampede_protection_validation.

Gates from #280

• Opt-in shipped in 0.3.9.
• Re-entrancy guard shipped.
• Live tests across backends exist.
• No open bugs against the feature.
• Per-miss overhead is now documented.