feat(observability): add Relay active install metrics

[afourniernv]

What does this PR do?

Adds the remaining Category 1 install/activation slice on top of the Relay client-resource stack. Consented Hermes session and task starts now emit an empty Relay activation mark, and the profile-scoped subscriber records one pseudonymous client-active counter per rolling 24-hour window.

This is a stacked PR on #68978. Until the earlier PRs land, GitHub shows the cumulative stack against main; the active-install-only diff is available here.

Stack Order

1. feat(observability): integrate NeMo Relay runtime and shared metrics #67607 - core Relay runtime, task metrics, aggregation, and local export.
2. feat(observability): report model and provider usage #68881 - bounded model metrics.
3. feat(observability): aggregate bounded tool metrics #68882 - bounded tool lifecycle and approval metrics.
4. feat(observability): aggregate bounded skill metrics #68883 - skill lifecycle, provenance, reuse, and reuse-after-patch metrics.
5. feat(observability): add Relay client resource metrics #68978 - bounded client OS, architecture, and install-method resources.
6. This PR - pseudonymous profile identity lifecycle and rolling active-install metrics.

Merge and review in this order. This PR is cumulative until its predecessors land on main.

Related Issue

Depends on #68978.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Emit an empty, allowlisted hermes.client.active Relay mark from consented session and task boundaries.
• Create a random profile-scoped UUID before the first active metric is persisted.
• Use one SQLite transaction for the install identity, rolling 24-hour compare-and-set latch, and counter increment so concurrent Hermes processes cannot double-count.
• Export the active-install metric with no dimensions; bounded client properties remain package resources and session/task identifiers never enter the event or package.
• Document reset semantics: removing the stopped profile's shared-metrics directory rotates identity while discarding its old aggregates and queued packages together.
• Extend the closed package schema, real-binding runtime coverage, cross-process tests, profile-isolation tests, and end-to-end smoke artifact.

How to Test

1. Run scripts/run_tests.sh tests/hermes_cli/test_relay_shared_metrics.py tests/hermes_cli/test_relay_shared_metrics_runtime.py -q.
2. Run the full stacked regression set documented in the PR validation comment.
3. Run .venv/bin/python scripts/smoke_nemo_relay_shared_metrics.py with the installed NeMo Relay binding.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS arm64

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

• Focused store/runtime suites: 244 passed.
• Full stacked regression set: 1,042 passed across 14 files.
• End-to-end installed-Relay smoke: passed with one hermes.client.active counter, a stable pseudonymous profile ID across packages, all prior aggregate families, schema validation, and privacy-canary checks.

[afourniernv]

Validation completed on the Category 1 stack tip:

• scripts/run_tests.sh tests/hermes_cli/test_relay_shared_metrics.py tests/hermes_cli/test_relay_shared_metrics_runtime.py -q: 244 passed.
• Full stacked regression set across Relay lifecycle, plugin, task, model, tool, skill, scheduler, store, and runtime coverage: 1,042 passed across 14 files.
• .venv/bin/python scripts/smoke_nemo_relay_shared_metrics.py: passed with the installed Relay binding. The exported packages contain one payload-free hermes.client.active metric, preserve one anonymous install ID across delta packages, validate against the closed schema, and contain none of the prompt/model/tool/skill privacy canaries.
• Cross-process activation regression confirms simultaneous starts increment the active-install metric once.
• Two-profile regression confirms each HERMES_HOME receives a distinct install identity and isolated active counter.

[afourniernv]

Two scope clarifications from review:

• The activity latch is intentionally a rolling 24-hour sliding window, not calendar-day DAU. The implementation and PR description already use that behavior; I will avoid calling it DAU or daily-active.
• The stable UUID is stored under one HERMES_HOME, so the current aggregation unit is an opted-in profile, not a physical Hermes installation. Profiles on the same machine receive separate IDs, and packages from one profile remain linkable until that profile's metrics state is reset.

I opened #69528 for the identity-scope decision. My recommendation for this local-first slice is to preserve the profile boundary and rename/document it as a random, resettable pseudonymous profile ID. Moving to a shared installation-level identity would first require explicit cross-profile consent, reset, deletion, and migration semantics.