stdlib: add a portable monotonic clock service

Status

The earlier service-family planning discussion selected a monotonic clock as the next candidate.
This issue now tracks that concrete post-stable feature. No clock service is part of the first stable
standard-library surface.

Goal

Provide elapsed-time measurement through an ordinary portable Silk service. The service exposes
monotonic time only: values never move backward within one provider and are suitable for durations,
timeouts implemented elsewhere, and performance measurements.

Wall-clock dates, calendars, time zones, and deterministic artifact timestamps are not part of this
service.

Proposed surface

pub struct Instant {
  ticks: u64
}

pub service MonotonicClock {
  effect fn now() -> Instant
}

A provider supplies the clock explicitly through the ordinary Effect requirement mechanism:

effect fn measure() -> u64 ? &MonotonicClock {
  let started = run MonotonicClock.now()
  let finished = run MonotonicClock.now()
  return Instant.elapsed(started, finished)
}

The exact Instant representation and helper names remain subject to specification.

Required decisions

Before implementation, specify:

• whether Instant is Copy or remains affine;
• whether values from different providers may be compared;
• tick-width, wrap, subtraction, and overflow behavior;
• whether an instant exposes its raw count or only comparison/duration operations;
• deterministic scripted-provider behavior for tests;
• the smallest target-neutral monotonic-time intrinsic;
• native and Wasm host-provider contracts.

Requirements

• The service and its data types are ordinary standard-library Silk declarations.
• Calls require an explicit provider; there is no ambient clock.
• A provider's observations are monotonic according to the specified comparison contract.
• The compiler does not recognize MonotonicClock or Instant by spelling.
• Evaluator, native, and Wasm behavior is deterministic under a scripted provider.
• Reading the clock must not introduce wall/calendar-time policy into the language.

Out of scope

• Wall-clock time, dates, calendars, time zones, and locale formatting.
• Sleeping, scheduling, concurrency, interruption, or cancellation.
• Build reproducibility timestamps.
• A default ambient provider.

Acceptance criteria

• An OpenSpec change resolves every required decision above.
• A scripted provider gives deterministic monotonic readings in all engines.
• A native provider uses a monotonic host source.
• Wasm exposes an explicit host import rather than an ambient JavaScript clock.
• Tests cover equal readings, increasing readings, wrap/overflow policy, and cross-provider use.
• No compiler phase or backend recognizes standard-library names.

Start with the OpenSpec change and resolve the listed Instant, provider, tick, overflow, and comparison decisions before implementation. Then trace the evaluator, native, and Wasm behavior described in the requirements and define deterministic scripted-provider tests. Done means the acceptance criteria pass without compiler phases or backends recognizing the standard-library names.