Decide long-term silverc strategy: vendor compiler vs pinned bootstrap

[trillskillz]

Summary

OpenSilver now has a working shared compiler bootstrap path at scripts/bootstrap-silverc.sh, and CI uses the same script to fetch/build the pinned upstream silverc binary.

That unblocks local dev and CI, but the broader packaging decision is still open:

• keep the current pinned-upstream bootstrap model, or
• vendor/distribute the compiler another way.

Why this matters

This choice affects:

• local onboarding friction
• CI stability and cache behavior
• whether downstream tools can assume silverc is present
• how OpenSilver eventually ships compile/deploy flows in CLI/MCP/Wizard

Current state

• pinned upstream ref: kaspanet/silverscript @ 2c46231
• bootstrap entrypoint: npm run bootstrap:silverc
• CI path: .github/workflows/ci.yml calls scripts/bootstrap-silverc.sh

Decision options

1. Keep pinned bootstrap

   • simplest now
   • matches current CI/local flow
   • depends on network + Rust toolchain at setup time

2. Vendor compiler artifacts or source more aggressively

   • lower setup friction for consumers
   • more repo/distribution complexity
   • needs a clear update policy for upstream pin bumps

Exit criteria

• pick the long-term strategy
• document it in README.md / NEXT_SESSION.md
• align CLI/MCP/deploy flows with the chosen assumption

[trillskillz]

Progress update:

• shared bootstrap is now landed in scripts/bootstrap-silverc.sh
• npm run bootstrap:silverc is wired into package.json
• CI now uses that same bootstrap path instead of duplicating clone/build logic
• SDK compile flows now surface a clear bootstrap hint when silverc is missing, and the test suite covers that path

Relevant commits:

• eb268ac — unify silverc bootstrap across local and ci
• $(git rev-parse --short HEAD) — hint silverc bootstrap when compiler is missing