feat(tooling): add TOOL_USAGE_COLLECTION_DB_PATH env var to override SQLite DB path

[NicolasMassart]

Description

The SQLite database path in scripts/tooling/db.ts was hardcoded to ~/.tool-usage-collection/events.db, making it impossible to redirect the database without modifying source code.

This PR introduces the TOOL_USAGE_COLLECTION_DB_PATH environment variable as an optional override. When set, openDb() uses that path; when absent, it falls back to the existing default.

A scripts/tooling/README.md is also added documenting the database location, the env var, the CLI, and the three collection paths.

Part of MCWP-448 — sub-task MCWP-539.

Changelog

CHANGELOG entry: null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/MCWP-539

Manual testing steps

Feature: TOOL_USAGE_COLLECTION_DB_PATH env var overrides the SQLite database path

  Background:
    Given I have the metamask-mobile repository checked out
    And I have run yarn setup

  Scenario: default database path is used when env var is not set
    Given TOOL_USAGE_COLLECTION_DB_PATH is not set in my shell environment

    When I run a yarn script that triggers tool-usage collection
    Then the events database is created at ~/.tool-usage-collection/events.db

  Scenario: custom database path is used when env var is set to a valid path
    Given I export TOOL_USAGE_COLLECTION_DB_PATH="/tmp/test-tooling/mydb.db"

    When I run a yarn script that triggers tool-usage collection
    Then the events database is created at /tmp/test-tooling/mydb.db
    And the directory /tmp/test-tooling is created automatically if it does not exist
    And no file is written to ~/.tool-usage-collection/events.db

Screenshots/Recordings

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1de2c1b. Configure here.}

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 99%

click to see 🤖 AI reasoning details

E2E Test Selection:
All three changed files are in scripts/tooling/ and relate exclusively to a local developer tool usage tracking system using SQLite. The changes include: (1) README.md documentation updates, (2) db.ts - a utility that opens/creates a local SQLite database for storing developer tool events, and (3) db.test.ts - unit tests for that database utility. These files have no connection to the app codebase, E2E test infrastructure, or any user-facing features. No app code imports from scripts/tooling/db.ts (confirmed via grep). The tooling system is a local-only developer utility that never affects the mobile app build, runtime behavior, or test execution. No E2E tests are needed.

Performance Test Selection:
The changes are limited to developer tooling scripts (local SQLite database for tool usage tracking). There is no impact on app performance, UI rendering, data loading, or any user-facing flows. No performance tests are warranted.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Cal-L]

Lgtm