feat: Linux build support + dynamic runtime paths

[scottzx]

Summary

• Linux platform support: Build script now detects OS (linux/darwin) and produces correctly-named artifacts
• Dynamic runtime paths: Settings API serves storePath / marketplacePath from backend, frontend no longer hardcodes macOS-only paths
• Unified Linux directories: On Linux, config/data/state lives under ~/.skill-manager
• Architecture naming: ARM64 → aarch64 for cross-platform consistency

Changes

File	Change
scripts/build_release.py	OS detection, Linux artifact naming, arch rename
skill_manager/paths.py	Linux: unified ~/.skill-manager root
skill_manager/application/settings/presenters.py	Expose storePath / marketplacePath in settings API
frontend/.../settings/api/types.ts	Add storePath / marketplacePath to interface
frontend/.../screens/SettingsPage.tsx	Remove hardcoded macOS paths

Verified

• Deployed on Linux ARM device (192.168.31.208:8000)

🤖 Generated with Claude Code

[SI-RUI-ZHANG]

Hi @scottzx, thank you for opening this. I really appreciate it, especially because this is one of the first external contributions to Skill Manager. Your Linux ARM validation is useful signal, and the direction is valuable.

I did an initial review. There are a couple of ideas here that I want to keep:

• exposing runtime paths from the backend instead of hardcoding macOS paths in the frontend
• making release artifacts OS/architecture-aware
• validating the app on Linux

I cannot merge this PR as-is because it also includes several unrelated changes, including i18n, a default port change, broad frontend rewrites, API error translation changes, and a snapshot/debug file. That makes the Linux support hard to review safely.

To keep the project history clean, I’m going to create a smaller maintainer branch for the Linux support work and credit this PR / your contribution in the PR description. I’ll keep the scope narrow: Linux paths, artifact naming, CI/package smoke, and Settings path display.

Thank you again. This PR is helpful as the starting point for Linux support, even if we don’t merge this exact branch.

[SI-RUI-ZHANG]

Hi @scottzx, thanks again for the contribution.

The Linux support from this PR has now landed through the smaller maintainer PR #25, which kept the scope focused and credited this PR.

I’m closing this one because it now has conflicts and includes unrelated changes beyond the Linux scope, including i18n, port changes, frontend rewrites, and debug/snapshot files.