feat(cluster): add MinerCluster — flips §3.7.1, §3.7.2

[jensholdgaard]

Summary

Two §5 invariant scenarios go from #[ignore] + todo!() to real
assertions in this single commit, jumping the §5 count from
4/29 to 6/29. This PR ships the multi-tenancy shape —
TenantId, MinerCluster with one TenantState per tenant —
but explicitly not the Drain tree.

What's in this PR

• ourios-core::tenant::TenantId — String-backed newtype
  (operator-facing slugs / UUIDs are String-shaped; column-store
  efficiency is the future ourios-parquet RFC's concern).
  No validation yet; future try_new can layer on top.
  AsRef<str> + Display for log lines / metric labels.
• ourios-miner::cluster::MinerCluster — public type
  holding HashMap<TenantId, TenantState> and a cluster-wide
  template_id allocator. Per-tenant state allocated lazily on
  first ingest. Public API: new, config, ingest,
  template_count, templates_for.
• ourios-miner::cluster::TenantState — private struct
  holding only the templates HashMap. Future PRs swap this
  for the real Drain tree.

Why the template_id allocator is cluster-wide, not per-tenant

RFC 0001 §6.1 uses the phrase "per-tenant monotonic" but also
requires that "two tenants emitting the structurally identical
template will have different template_ids," and §5 §3.7.2
requires "no template_id is shared across tenants." A truly
per-tenant allocator gives both tenants id=1 for their first
template and silently violates §3.7.2 — the test caught this on
first run (id_a == id_b == 1 failure). Reconciliation: the
id space is cluster-wide, but each tenant's slice of that
space is monotonic with respect to that tenant's allocation
order. Both phrases hold:

• "per-tenant monotonic" — given a tenant, the sequence of
  ids allocated to that tenant strictly increases over time.
• "different template_ids across tenants" — the shared
  allocator never hands out the same id twice.

A code comment on next_template_id documents this so future
readers don't try to "fix" it back into per-tenant.

What's not in this PR (deferred)

• Drain tree — no simSeq, no depth-bounded tree, no
  widening. The cluster's per-tenant store is a HashMap keyed
  on the masked-token sequence (exact-match templating). Future
  PR replaces with RFC §6.2 steps 3–5.
• Audit events, telemetry, body retention, lossy_flag —
  follow once the tree exists.
• Parquet record emission — ourios-parquet's problem.
• Tenant lifecycle (TenantPaused, TenantDeleted,
  eviction) — RFC §9 deferral, future PR.

§5 stubs flipped

Scenario	Test	Approach
§3.7.1	invariant_3_7_1_tenant_trees_never_cross_pollinate	Two tenants emit different shapes; interleaved ingest. Asserts on token-set membership: A's tree contains A-shape tokens, B's contains B-shape tokens, neither contains the other's.
§3.7.2	invariant_3_7_2_same_template_two_tenants_distinct_template_ids	Two tenants emit the identical line. Asserts id_a != id_b (the bug the cluster-wide allocator fixes).

Plus 4 cluster unit tests in cluster.rs:
ingest_returns_same_template_id_for_repeat_shape,
ingest_returns_distinct_template_ids_for_distinct_shapes,
template_count_is_zero_for_unseen_tenant,
ingest_lazily_allocates_per_tenant_state.

All AAA-structured per the new policy.

Cargo dependency change

ourios-miner promotes ourios-core from [dev-dependencies]
to [dependencies] — the cluster module now imports
ourios_core::config::MinerConfig and ourios_core::tenant::TenantId
from non-test code. The single dep entry covers both production
code and the integration tests.

Lifecycle

Per docs/verification.md §3 two-loop spec:

• Outer loop: 15 → 21 passed (+4 cluster unit tests, +2
  newly green §5 scenarios); 25 → 23 ignored (−2 flipped).
• Inner loop: 25 → 23 failed.
• §5 scenario count toward Green: 4/29 → 6/29.

RFC 0001 stays at status: red (23 stubs remaining).

Invariant / hazard impact (CLAUDE.md §§3, 4)

• §3.7 (multi-tenancy is not bolted on). TenantId is now
  the entry-point type; MinerCluster::ingest requires it for
  every line. There is no code path in the cluster that touches
  template state without a TenantId.
• The §3.7 invariant's "every code path that touches data takes
  a tenant ID" is satisfied for the cluster surface; future
  Parquet/WAL surfaces will need to thread it through too.

Test plan

• cargo fmt --all --check clean
• cargo clippy --all-targets --all-features -- -D warnings clean
• cargo test --all-features — 21 passed, 23 ignored
• mdbook build clean

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Introduces the initial multi-tenant “cluster” surface for the miner by adding a TenantId type in ourios-core and a MinerCluster in ourios-miner that maintains isolated per-tenant template state while allocating globally-unique template_ids. This also flips two previously-ignored RFC invariants (§3.7.1/§3.7.2) into real assertions.

Changes:

• Add ourios_core::tenant::TenantId (String-backed newtype) and export it from ourios-core.
• Add ourios_miner::cluster::MinerCluster (per-tenant template stores + cluster-wide template_id allocator) and export the module.
• Convert invariant tests §3.7.1 and §3.7.2 from #[ignore] + todo!() into executable tests; promote ourios-core to a normal dependency for ourios-miner.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
crates/ourios-miner/tests/invariants.rs	Flips §3.7.1/§3.7.2 invariant scenarios into real tests using MinerCluster + TenantId.
crates/ourios-miner/src/lib.rs	Exposes the new cluster module publicly.
crates/ourios-miner/src/cluster.rs	Implements the multi-tenant cluster wrapper and per-tenant template storage + unit tests.
crates/ourios-miner/Cargo.toml	Promotes ourios-core from dev-dependency to normal dependency for production code usage.
crates/ourios-core/src/tenant.rs	Adds the TenantId newtype and basic string access/display helpers.
crates/ourios-core/src/lib.rs	Exports the new tenant module.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.