Profiles: add local player profiles and isolated learning progress

[Codewriter90x]

Summary

Add local player profiles so multiple people can use the same HitTheKit installation without overwriting one another's learning progress, practice history, results, or preferences.

This foundation should remain local-first. It must not require an account, email address, cloud service, or backend.

User experience

When no profile exists, guide the player through creating the first one.

When multiple profiles exist, show a Who's playing? screen at startup with:

• display name;
• one original preset avatar;
• practice level or progress summary when available;
• total practice time;
• most recent activity;
• create-profile action;
• manage-profile action.

When exactly one profile exists, the application may open it automatically while keeping profile switching available from the main menu or Settings.

An optional Play as guest entry may allow a temporary session that does not modify persistent player progress.

Profile identity

Each profile should contain only the minimum local identity data:

• stable internal profile ID;
• player-chosen display name;
• preset avatar ID;
• creation timestamp;
• last-used timestamp.

Preset avatars must be original project assets. Do not collect a real name, email address, date of birth, photograph, or other unnecessary personal information.

Profile-scoped data

The following data should belong to the active player profile:

• learning-path and lesson progress;
• unlocked lessons or exercises;
• song and lesson results;
• accuracy, high scores, streaks, and personal bests where supported;
• total and per-session practice time;
• per-song and per-lesson statistics;
• practice speed and difficulty preferences;
• training preferences that affect the individual learning experience;
• first-encounter/tutorial state;
• accessibility preferences when they are intended to follow the player.

All persistence APIs must require an explicit profile identity or an active-profile context. A profile must never read or mutate another profile's progress accidentally.

Device-scoped data

The following data should remain shared by the installation unless a later requirement proves otherwise:

• MIDI device discovery and hardware configuration;
• electronic-drum mappings and local device profiles;
• audio output and technical graphics settings;
• local song-library folders;
• local audio bindings and machine-specific file paths;
• application update and installation settings.

The application language may remain installation-wide initially. If it becomes profile-specific later, that policy must be explicit and migration-safe.

Profile management

Players should be able to:

• create a profile;
• select and switch profiles outside an active gameplay session;
• rename a profile;
• change its preset avatar;
• export a profile backup;
• import a compatible profile backup;
• delete a profile only after a clear confirmation;
• understand which profile is currently active.

Switching profiles during an active lesson or song must be rejected or deferred until the session ends.

Backup boundary

Support both:

1. exporting a single profile;
2. exporting all local profiles when appropriate.

Backups must not automatically contain:

• commercial audio;
• local audio files;
• machine-specific absolute paths;
• credentials or secrets;
• hardware identifiers that are not required for portable progress.

Import must validate the schema and avoid silently overwriting an existing profile. Profile-ID collisions need an explicit merge, replace, or create-copy policy.

Migration

Existing installations currently using unscoped progress must migrate safely:

• create one default local profile;
• attach existing compatible progress and practice history to that profile exactly once;
• preserve device-scoped configuration;
• make the migration idempotent;
• retain a recoverable backup until migration succeeds.

Acceptance criteria

• A new installation can create and select its first local profile.
• Two profiles can complete different lessons without affecting each other.
• Results, statistics, unlocks, and practice time are isolated by profile.
• Shared MIDI/device and local song configuration remains available to both profiles.
• The active profile is visible in the main experience and can be switched outside gameplay.
• Profile switching is prevented or safely deferred during an active session.
• Renaming or changing an avatar does not change the stable profile ID.
• Deleting a profile requires confirmation and cannot delete another profile's data.
• Single-profile and all-profile backups round-trip deterministically.
• Import rejects malformed, incompatible, or ambiguous backups without partial state.
• Backups contain no commercial media, credentials, or machine-specific absolute paths.
• Existing unscoped progress migrates once to a default profile without resetting hardware configuration.
• Automated tests cover creation, selection, isolation, switching, deletion, migration, backup, import, and failure atomicity.
• The profile-selection screen works with mouse, keyboard, and supported drum-navigation input.

Out of scope

• online accounts;
• passwords or PIN protection;
• cloud synchronization;
• social profiles or leaderboards;
• remote avatars or user-uploaded photographs;
• parental-control or identity-verification systems;
• backend services.

These can be evaluated later without making local profiles depend on them.