fix(ets): route ETS-specific functions through sandbox adapter

[BobbieBarker]

Summary

• ETS-specific functions (update_counter/2, update_counter/3, insert_raw/1, match_object/1, match_object/2) were bypassing sandbox isolation by calling :ets directly instead of routing through @cache_adapter
• Added defoverridable wrappers in the __using__ macro (lib/cache.ex) that prefix keys via maybe_sandbox_key and dispatch through @cache_adapter when sandbox?: true and adapter: Cache.ETS
• The sandbox adapter (Cache.Sandbox) already had implementations for these functions — they just were never called from the generated module

Test plan

• Added test/cache/ets_sandbox_test.exs with 11 tests verifying sandbox isolation for all affected functions
• Each function has a test that writes data and a separate test verifying the data is not visible (isolation)
• All existing tests pass (126/127 — the 1 failure in redis_json_test.exs is pre-existing and unrelated)

[MikaAK]

I think this is a fundamental problem with the ets adapter, it probably should be calling something the module attribute to allow the sandbox switchover 🤔

[cking222]

I think this is a fundamental problem with the ets adapter, it probably should be calling something the module attribute to allow the sandbox switchover 🤔

I am open to feedback. If you want this to work differently let me know. I was optimistically trying to use the new ETS functionality you added, and found out that these functions don't play nice with the sandbox, so i whipped something up to cover the gap.