docs: cleanup documents (#1111)

* fix invalid link README.md

 [air.rs](./air.rs) is invalid. Changed to  [air.rs](./src/air.rs)

* fix invalid link README.md

"[Writing the Guest Program](../../benchmarks/README.md#writing-the-guest-program" is invalid.

Changed to "[Writing the Guest Program](../../../benchmarks/README.md#writing-the-guest-program"

* fix invalid link README.md

"[fibonacci example](./bin/fibonacci.rs)" is not working.

Changed to "[fibonacci example](./src/bin/fibonacci.rs)".

* fix invalid link sdk.md

"[Overview of Basic Usage](./overview.md)" is invalid.

Changed to "[Overview of Basic Usage](../writing-apps/overview.md)".

* fix invalid link benchmarks.md

"[github workflows](./.github/workflows/benchmark-call.yml)" is invalid link.

Changed to "[github workflows](../../.github/workflows/benchmark-call.yml)".

* fix typo ISA.md

- "an memory access" -> "a memory access"

The phrase "an memory access" is considered incorrect because the article "an" is used before words that begin with a vowel sound. Since "memory" starts with a consonant sound, the correct article to use is "a," making it "a memory access."

book/src/advanced-usage/sdk.md

@@ -2,7 +2,7 @@
 
 While the CLI provides a convenient way to build, prove, and verify programs, you may want more fine-grained control over the process. The OpenVM Rust SDK allows you to customize various aspects of the workflow programmatically.
 
-For more information on the basic CLI flow, see [Overview of Basic Usage](./overview.md). Writing a guest program is the same as in the CLI.
+For more information on the basic CLI flow, see [Overview of Basic Usage](../writing-apps/overview.md). Writing a guest program is the same as in the CLI.
 
 ## Imports and Setup
 

crates/toolchain/tests/README.md

@@ -6,7 +6,7 @@ This crate includes tests for OpenVM toolchain that involve starting from a Rust
 
 1. Add a new guest program file to [programs/examples](./programs/examples).
 
-See [Writing the Guest Program](../../benchmarks/README.md#writing-the-guest-program) for more detailed instructions.
+See [Writing the Guest Program](../../../benchmarks/README.md#writing-the-guest-program) for more detailed instructions.
 
 The `programs` directory is a single crate to make it easier to add small test programs. The crate is **not** part of the main workspace.
 Your IDE will likely not lint or use rust-analyzer on the crate while in the workspace, so you should open a separate IDE workspace from `programs` while writing your guest program.

docs/crates/benchmarks.md

@@ -3,7 +3,7 @@
 ### Latest Benchmark Results
 
 Latest benchmark results can be found [here](https://github.com/openvm-org/openvm/blob/benchmark-results/index.md).
-These are run via [github workflows](./.github/workflows/benchmark-call.yml) and should always be up to date with the latest `main` branch.
+These are run via [github workflows](../../.github/workflows/benchmark-call.yml) and should always be up to date with the latest `main` branch.
 
 ### Adding a Benchmark
 

docs/specs/ISA.md

@@ -21,7 +21,7 @@ The program code is committed as a cached trace. The validity of the program cod
 Memory is comprised of addressable cells, each cell containing a single field element.
 Instructions of the VM may access (read or write) memory
 as single cells or as a contiguous list of cells. Such a contiguous list is called a _block_, and
-an memory access (read/write) to a block is a _block access_.
+a memory access (read/write) to a block is a _block access_.
 The architecture distinguishes between block accesses of different sizes as this has significant performance implications.
 The number of cells in a block access is restricted to powers of two, of which the following are supported: 1, 2, 4, 8, 16, 32, 64. Block accesses must be
 aligned, meaning that in a block access of size $N$, the starting pointer must be divisible by $N$ (as an integer).

extensions/keccak256/circuit/README.md

@@ -25,7 +25,7 @@ It seems to handle padding in a single AIR row there is no alternate to having `
 The absorb step must correctly constrain that the input bytes are XORed with the end-state in the last round and equals the next permutation's `preimage`. The end-state is accessed via `a_prime_prime_prime()`. Note that both `preimage` and `a_prime_prime_prime()` are represented as `u16`s. However we can only XOR at most 8-bit limbs. Without changing the `keccak-f` AIR itself, we can use a trick:
 if we already have a 16-bit limb `x` and we also provide a 8-bit limb `hi = x >> 8`, assuming `x` and `hi` have been range checked, we can use the expression `lo = x - hi * 256` for the low byte. If `lo` is range checked to `8`-bits, this constrains a valid byte decomposition of `x` into `hi, lo`. This means in terms of trace cells, it is equivalent to provide `x, hi` versus `hi, lo`.
 
-The constraints are in [air.rs](./air.rs). Notably we use an XOR lookup table for byte XORs in the absorb step.
+The constraints are in [air.rs](./src/air.rs). Notably we use an XOR lookup table for byte XORs in the absorb step.
 
 ## Future Improvement