Upgrades for name token and registrar.

[zie1ony]

This pull request introduces several important updates across the codebase, focusing on upgrading dependencies, adding a new upgrade scenario for the Registrar contract, improving timestamp handling, and refining contract logic. The most notable changes are summarized below.

Dependency and Toolchain Upgrades:

• Upgraded all odra workspace dependencies from version 2.4.0 to 2.8.1 in Cargo.toml, ensuring compatibility with the latest features and fixes.
• Updated the Rust toolchain to use nightly-2026-01-01 instead of nightly-2025-01-01.

New Scenario & CLI Enhancements:

• Added a new UpgradeRegistrar scenario to the CLI, allowing the Registrar contract to be upgraded via the command line. This includes implementing the scenario logic and registering it in the CLI entrypoint. [1] [2] [3]

Contract Logic Improvements:

• Improved the timestamp handling in the Registrar contract by introducing a utility function trim_microseconds_to_milliseconds_if_needed, which prevents bugs caused by off-chain systems supplying timestamps in microseconds instead of milliseconds. This function is now used in the expiration check, and unit tests have been added for it. [1] [2] [3]
• Simplified the NameToken contract's transfer logic by using raw_transfer instead of manually fetching the owner and calling raw_transfer_from.

Deployment Script Adjustments:

• Updated deployment scripts to pass an additional None parameter to load_or_deploy_with_cfg calls for all contract components, aligning with updated API requirements. [1] [2] [3] [4] [5]

These changes collectively enhance contract upgradability, improve robustness against off-chain integration issues, and keep the project up to date with the latest dependencies and toolchain.

[ZhmakAS]

Please remove trim_microseconds_to_milliseconds_if_needed(...) from all metadata write/storage paths.

The off-chain CSPR.cloud code still sends expiration in microseconds and also reads token metadata assuming microseconds. After the recent contract changes, the contract trims the value before saving metadata, so newly created tokens are stored with expiration in milliseconds. That creates an inconsistent state between old and new tokens and breaks the expiration job.

Current problem:

• off-chain sends voucher/token expiration in microseconds
• contract trims it to milliseconds before storing metadata
• the job later reads metadata and parses expiration as microseconds
• for newly created tokens, this makes the job think the token expired long ago
• the job keeps calling expire
• but on-chain, the contract compares against the milliseconds value, so the token is not burnable yet
• result: no Burn event is emitted and the job retries the same tokens

We should preserve metadata exactly as provided by off-chain. Please keep the normalization only in the expire path, where the contract reads existing token metadata and checks whether it can be burned. That way we support legacy microsecond metadata without mutating stored metadata units.

In short:

• do not trim when creating token metadata
• do not trim when updating token metadata
• do not trim in NameTokenMetadata::with_resolver
• do not trim in NameTokenMetadata::with_no_resolver
• do not trim in NameTokenMetadata::set_expiration
• do not trim in deserialization paths if the deserialized metadata may later be written back to storage
• normalize only when reading/checking expiration in the expire logic

сс @zie1ony