Run your own skill from anywhere: --skill-file with URLs, and shared skill packs #93

Problem: #79 lets a user drop a skill file in ~/.secfoo/skills/ or point [skills] paths at a folder, and run a one-off file with secfoo run --skill-file ./my-skill.md. That covers one machine. It doesn't cover the two ways skills actually get shared: a teammate sends a link, or a team keeps its skills in a git repo and wants everyone (and CI) on the same pinned version.

Goal: run a skill from a file, a URL or a shared pack with one command, with the same safety rules as #79, and have the dashboard show which skill text produced each report.

Build:

1. --skill-file accepts URLs. secfoo run --skill-file https://.../graphql-review.md <target> fetches over HTTPS only (no http://, no redirects to http://), caps size (256 KB), validates the file exactly like a local skill (Custom skills: add your own skills without changing code #79 rules: frontmatter, id format, no clash with built-ins) and runs it. --skill-sha256 <hex> pins the content for CI; a mismatch is an error before anything runs.
2. Skill packs. A pack is a git repo (or a local folder) containing *.md skills, optionally under skills/:

   secfoo skills install https://github.com/acme/appsec-skills            # clones to ~/.secfoo/skills/packs/acme-appsec-skills
   secfoo skills install https://github.com/acme/appsec-skills --ref v3   # tag, branch or commit
   secfoo skills update [NAME]                                            # fetch and move to the ref's newest commit
   secfoo skills remove NAME
   secfoo skills list                                                     # shows pack and commit for each skill (extends #79's list)

   ~/.secfoo/skills/packs.lock records url, ref and resolved commit for every pack, so secfoo skills install --from-lock reproduces the set in CI. Pack skills load through Custom skills: add your own skills without changing code #79's loader like any other folder; a pack skill whose id clashes with another pack or a built-in is skipped with a warning naming both files.
3. Trust at the point of use. Skill text becomes agent instructions, so the first run of any skill that didn't come from the built-ins or ~/.secfoo/skills/*.md prints the skill id, name, source and sha256 and asks for confirmation. --yes (and non-TTY) skips the prompt; the run still records what ran. Skills are never read from the target being scanned (Custom skills: add your own skills without changing code #79), including a target that happens to be a skill pack.
4. Traceability in the dashboard. Custom skills: add your own skills without changing code #79 adds skill_version, skill_source and skill_sha256 to runs. Extend skill_source to carry the URL or pack:<name>@<commit>, show it on the run detail page, and on the activity page group runs of the same skill id even when they came from different sources, with the source visible per run. A skill that changed between two runs (different sha256) gets a small "definition changed" marker on the later run.
5. Docs: extend docs/SKILLS.md from Custom skills: add your own skills without changing code #79 with "Sharing skills with your team" (a pack repo layout, pinning, CI setup) and the trust model.

Where to look: src/secfoo/cli.py (run, the skills group from #79), src/secfoo/skills/loader.py, src/secfoo/settings.py / config.py, src/secfoo/web/routes/runs.py and templates/run_detail.html, src/secfoo/storage/schema.sql.

Relation to #79: depends on #79's loader, --skill-file and the runs columns. Coordinate in that thread on the skills CLI group so the subcommands land in one place.

Done when: tests cover: --skill-file with an HTTPS URL (served by a local test server), rejection of http://, a size cap hit, a sha256 mismatch; installing a pack from a local git repo at a tag, update moving to a new commit, --from-lock reproducing it; an id clash between a pack and a built-in being skipped; the trust prompt appearing once and --yes bypassing it; and the run detail page showing the source and the "definition changed" marker.