chore: update Anchor version

[IaroslavMazur]

Depends on #86.

chore: remove the bytemuck dependency hotfix
chore: update other dependencies

Note: We shouldn't reference a specific Rust toolchain version from the past, as it'll, normally, become incompatible with the rest of the dependencies quite soon - and require regular maintenance.

Referencing the generic toolchain kind (i.e. nightly or stable) is the way.

[andreivladbrg]

We shouldn't reference a specific Rust toolchain version from the past, as it'll, normally, become incompatible with the rest of the dependencies quite soon - and require regular maintenance.

that's correct only if we update the other dependencies as well, right?
the idea is to have a stable version of deps — so that we won't update them constantly, causing continuous refactors

my motivation for having a fixed version for building the program is to make it pass no matter what someone uses locally — it may be 2025-04-01 or not — but we should aim, IMO, for a stable version

[IaroslavMazur]

that's correct only if we update the other dependencies as well, right? the idea is to have a stable version of deps — so that we won't update them constantly, causing continuous refactors
my motivation for having a fixed version for building the program is to make it pass no matter what someone uses locally — it may be 2025-04-01 or not — but we should aim, IMO, for a stable version

Generally speaking, we should either "pin" all of the tool versions (for Rust, Anchor & Solana) - or none, at all, because, sometimes, they develop independently, leading to incompatibilities between them (this is what happened recently, e.g.).

Now, I'm not sure it'd be a good idea to enforce any specific tool version in either the bun scripts or the GitHub workflows, because together with "making the build pass" (when this can "fix" any local config issues), this would, also, hide/obfuscate any tool version compatibility issues in case (partially) pinning them is not enough. The latter would make fixing the root cause of the issue harder.

The argument for not enforcing the tool versions in bun scripts is identifying any compatibility issues sooner (i.e. not hiding them if there are any in the local env config of the developer), and in GH workflows - because that's the last level of validations that's happening before the code is being integrated into main - and, then, deployed on-chain.

Open for further discussion.