Fix possible fix(deps): 6 vulnerable dependencies in Gemfile.lock

[begininvoke]

Small change to Gemfile.lock — a scan flagged the code below and it looked genuine. It is around line 69.

Vulnerable dependency found: concurrent-ruby 1.2.3 (Gemfile.lock, line 69) is affected by CVE-2026-54906, rated CRITICAL, fixed in >= 1.3.7. The flaw is in the Concurrent::ReadWriteLock synchronization API: (1) release_write_lock does not verify that the calling thread owns the write lock, so any thread with access to the lock object can release a write lock held by another thread, letting a second writer enter its critical section while the first is still running — a race condition that can cause data corruption, inconsistent state, or security-relevant TOCTOU bugs in code protected by the lock; (2) release_read_lock decrements the shared counter even when no read lock is held, so a stray call drives the counter to -1 and all subsequent read acquisitions raise Concurrent::ResourceLimitError, enabling an availability/denial-of-service failure. Impact is highest if the application or its gems (e.g., Rails concurrency internals) actually use ReadWriteLock, but since this is a public API correctness bug, upgrading is low-risk and strongly recommended. Fix by upgrading to concurrent-ruby 1.3.7 (a compatible patch release for existing ~> 1.x constraints, including Rails') and regenerating the lockfile.

Updated vulnerable gem versions (concurrent‑ruby, rexml, activesupport, addressable, faraday) to the minimum secure releases and relaxed the rexml constraint in xcodeproj to allow the newer version, preserving all existing dependencies.

For reference: rule CVE-2026-54906. Rated critical.

Take or leave whichever parts are useful. If this is not the right approach, closing is fine.

---

Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.