Fixes the `verify_stark` integration test following some folder
reorganization.

close INT-4031

---------

Co-authored-by: Jonathan Wang <[email protected]>
Co-authored-by: HrikB <[email protected]>

Runs the `verify-stark` integration test in CI

)

With the v1.3.0-rc release, we moved to supporting `getrandom v0.3`.
However some libraries like `ecdsa` still use `getrandom v0.2` and it
would give the unsupported backend error.

Turns out it is possible to support both simultaneously.

Closes INT-4187

# Add versioning compatibility workflow for INT-4160

## Overview

This PR implements a new GitHub workflow to enforce OpenVM's versioning
policy as described in ticket INT-4160. The workflow verifies that
verification keys remain consistent between the main branch and the
latest patch version (v1.2.0).

## Changes

- **New workflow file**: `.github/workflows/versioning.yml`
- **Workflow functionality**:
  - Runs `cargo openvm keygen` with default config on the main branch
  - Runs `cargo openvm keygen` with default config on v1.2.0 tag
- Compares the generated verification keys (`app.vk`) using `cmp`
command
- Fails the workflow if verification keys differ, indicating a
versioning policy violation

## Technical Implementation

The workflow follows the established patterns in the repository:
- Uses the same runner configuration as other workflows
(`32cpu-linux-arm64`)
- Includes proper Rust toolchain setup and caching
- Installs the CLI tool using `cargo install --force --path crates/cli`
- Uses default keygen configuration (no custom config file specified)
- Outputs keys to separate directories for comparison

## Versioning Policy Enforcement

As stated in `VERSIONING.md`, the core principle is: **"Patch upgrade
should be backward compatible"**. This means the verification key
(`MultiStarkVerifyingKey`) must not change across patch versions. This
workflow automatically verifies this requirement.

## Testing

The workflow has been structured based on existing patterns in the
codebase:
- Follows the same YAML structure as other workflows in
`.github/workflows/`
- Uses the same actions and runner configurations
- Implements the keygen functionality as described in
`crates/cli/src/commands/keygen.rs`

Successful test run here:
https://github.com/openvm-org/openvm/actions/runs/15722075897/job/44304740887

## Ticket Reference

- **Linear Ticket**: INT-4160
- **Link to Devin run**:
https://app.devin.ai/sessions/b18b4684e92c44daabd69e34e47bd138
- **Requested by**: Yi Sun

## Workflow Triggers

- Runs on push to `main` branch
- Supports manual dispatch via `workflow_dispatch`

---------

Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Co-authored-by: Yi Sun <[email protected]>
Co-authored-by: Hrik Bhowal <[email protected]>

For reasons I am not entirely clear on, when you use
`getrandom_v02::Error`, the `getrandom` crate pulls in `std` library.
But if you just directly implement what the `register_custom_getrandom!`
macro does, this goes away...

Fixes CI failure.

Full disclosure: I got the idea from
https://github.com/risc0/risc0/pull/3106/files#diff-fd010fc66ba8d918981d2705c0d10cd65d19db599969bb29bb14caffa62d3b65R95

## Summary
- Updates the version command to display in the format `v1.3.0-rc.1
(abc123...)` instead of showing build timestamp
- Adds version tag to openvm dependency when running `cargo openvm init`
- Dependencies now include `tag = "v1.3.0-rc.1"` for reproducible builds

## Changes
1. Modified `OPENVM_VERSION_MESSAGE` in `crates/cli/src/lib.rs` to show
version and commit hash
2. Updated `crates/cli/build.rs` to only emit git SHA (removed build
timestamp)
3. Enhanced `add_openvm_dependency` function in
`crates/cli/src/commands/init.rs` to include version tag

## Test plan
- [x] Built cargo-openvm with `cargo build -p cargo-openvm`
- [x] Tested version command: `./target/debug/cargo-openvm openvm
--version` outputs `v1.3.0-rc.1 (46160dd)`
- [x] Tested init command: `cargo openvm init` now adds dependency with
version tag

🤖 Generated with [Claude Code](https://claude.ai/code)

---------

Co-authored-by: Claude <[email protected]>

Separates the functions exposed by guest libs into their own section in
the book.

Closes INT-4294

---------

Co-authored-by: Jonathan Wang <[email protected]>

And update on support for both getrandom v0.2 and v0.3.

closes INT-4186

Clarify that OpenVM's use of the Harvard architecture and how it relates
to reflective programming.

Closes INT-4352

---------

Co-authored-by: Yi Sun <[email protected]>

Currently if we change the workspace version before tagging, the
integration test for `cargo openvm init` will break because it creates a
guest crate that references the tagged version. I updated the test so it
patches to the local openvm if the environmental variable
`USE_LOCAL_OPENVM=1` is set.