fix: make slashing penalty calculation race-safe

[drojas1316]

Closes #212

Summary

Fixes the slashing penalty race described in #212 by ensuring the active validator count and slashing event are handled inside the same PostgreSQL transaction.

The implementation serializes validator-set changes against penalty calculation, persists the validator count used at the exact slashing point, and adds deterministic concurrency coverage for joins, activation, deactivation, and concurrent slashing operations.

Related issue

Closes #212

What changed

• Added validator_registry as the authoritative validator-set membership table.
• Added active_validators as a view over active registry entries.
• Added slashing_events with persisted validator_count_at_slashing.
• Added ValidatorRegistry for validator registration, activation, deactivation, and active-set queries.
• Added monetary calculatePenalty() logic using the required base penalty of 500 tokens.
• Added SlashingExecutor to calculate and persist penalties atomically.
• Added migration 012_slashing_penalty_consistency.sql.
• Added deterministic concurrent race tests.

Transaction consistency

Each slashing event uses a single PostgreSQL client and follows this exact order:

BEGIN ISOLATION LEVEL SERIALIZABLE
LOCK TABLE validator_registry IN SHARE ROW EXCLUSIVE MODE
SELECT COUNT(*) AS count FROM active_validators
calculate penalty
INSERT INTO slashing_events (..., validator_count_at_slashing)
COMMIT

On failure, the transaction is rolled back and the client is always released.

This prevents validator joins or leaves from becoming visible between the active-set snapshot and the persisted slashing event.

Race behavior

If slashing acquires the registry lock first:

1. The active validator count is read.
2. Concurrent validator-set changes wait.
3. The slashing event is persisted with that historical count.
4. Slashing commits.
5. The membership change proceeds.

If the membership update commits first, the following slashing transaction sees the new count.

Both outcomes correspond to a valid serial execution.

Penalty calculation

The protocol base penalty is fixed at 500 tokens.

The multiplier is:

1 + (totalValidators - activeValidators) / totalValidators

Active / Total	Multiplier	Penalty
10 / 10	1.00	500
3 / 4	1.25	625
0 / 10	2.00	1000

Invalid validator counts are rejected instead of silently clamped.

Concurrent coverage

The focused tests cover:

• a new validator being registered while slashing holds the registry lock
• activation during slashing
• deactivation during slashing
• membership mutation completing before slashing
• two concurrent slashing transactions
• historical snapshot stability after membership changes
• exact transaction query ordering
• rollback behavior on count, calculation, insert, and commit failures
• client release on success and failure paths
• formula boundaries and invalid inputs

The concurrent registration test verifies that the new validator is not visible until slashing commits, while the stored event retains the original validatorCountAtSlashing.

Validation

Focused race test:

npx tsx tests/slashing/penalty_calculator_race.test.ts
slashing penalty consistency tests passed

Focused strict TypeScript compilation:

PASS — no diagnostics

Existing migration regression:

npx tsx tests/database/migration_manager.test.ts
PASS

Whitespace validation:

git diff --check
PASS

Repository baseline note

The full repository build continues to encounter pre-existing TypeScript parser errors in src/api/metrics/prometheus.ts.

That unrelated file was not modified by this PR.

No existing key-rotation code, staking balance behavior, package dependencies, lockfiles, CI configuration, or unrelated source modules were changed.