Alias storages open a new empty storage after a migration or reboot #1254

On the platform, a storage opened by an alias that is not declared in the Actor schema (Actor.open_dataset(alias=...), KeyValueStore.open(alias=...), etc.) does not survive a migration or reboot. After the restart, the alias opens a new, empty unnamed storage. The data written before the restart stays in the old storage, which is orphaned.

The SDK E2E tests test_dataset_aliases, test_kvs_aliases, and test_rq_aliases fail for this reason, while other reboot tests pass (example run).

Root cause

The SDK saves a map of aliases to storage IDs in the run's default key-value store (__STORAGE_ALIASES_MAPPING). The key of each entry is <type>,<alias>,<hash(api_public_base_url + token)> (src/apify/storage_clients/_apify/_alias_resolving.py, _storage_key; hash in src/apify/storage_clients/_apify/_utils.py, hash_api_public_base_url_and_token).

The platform now gives a run a new API token when it migrates or reboots. After the restart, the SDK computes a different key, finds no entry, and creates a new storage. Storages declared in the Actor schema are not affected, because the platform resolves them through ACTOR_STORAGES_JSON.

The token is in the key so that the same alias opened with credentials of two different users maps to two different storages.

Expected behavior

An alias opened with the run's own credentials resolves to the same storage after a migration, reboot, or resurrection. Aliases opened with different users' credentials still map to different storages.

A possible fix: build the key from the user ID instead of the token. For the run's own token, take it from APIFY_USER_ID (Configuration.user_id). For another user's token, keep the token hash, or get the user ID with GET /users/me.

The JS SDK v4 has the same bug: apify/apify-sdk-js#865.