asim: poor observability of simulation time/ticks

The allocator simulator (asim) currently uses raw `time.Time` values to represent logical simulation ticks. This approach has several drawbacks that hinder development and debugging:

**Problems:**

1. **Poor log readability**: When `time.Time` values appear in logs, they're verbose and don't clearly convey the logical progression of the simulation. Manual formatting is required to make tick values meaningful.

2. **No semantic distinction**: Using `time.Time` for logical ticks conflates wall-clock time with simulation steps, making the code less clear about whether a value represents real time or a simulation tick.

3. **Difficult to track simulation progress**: There's no compact, human-readable representation of "which tick we're at" without additional conversion logic scattered throughout the codebase.

4. **Harder debugging**: When analyzing simulation behavior, developers need to mentally convert timestamps to understand the logical sequence of events.

**Proposed solution:**

Introduce an explicit `Tick` type that:
- Encapsulates the tick index, start time, and interval
- Provides a compact, sortable string representation (e.g., "t0042")
- Makes simulation time handling explicit in APIs and interfaces
- Improves log output readability

This will make the simulator more maintainable and easier to debug by providing clear, semantic types for simulation time tracking.

**Related:**
- Fixes #156517

Epic CRDB-56265
Jira issue: CRDB-56045

Start by locating the allocator simulator (asim) code that uses raw time.Time values for logical ticks and trace how simulation time appears in its APIs, interfaces, and logs. Define the scope of the Tick type around the stated tick index, start time, interval, and compact representation; done means simulation time is explicit and logs clearly identify the current tick.

Written by the indexing model from the issue text.