Report the version, and ship as v0.1.1

[danielholanda]

Report the version, and ship as v0.1.1

Stacked on #10. This targets dholanda/simplify, so the diff here is just what
I'd change about that PR — merge it into #10 and #10 stays the one that goes to
main.

#10 has the right idea: job.workflow_sha derives the harness from the ref the
caller pinned, so it is correct at a tag, at main, and on a branch, with no
literal to keep in step and no release ritual. That is why this is stacked on it
rather than on #11. Three things it needs first.

The version output says .skillscope-action

The launcher reported GITHUB_ACTION_REF or source.name. Through the reusable
workflows the action is local — uses: ./.skillscope-action — so
GITHUB_ACTION_REF is empty and the fallback is the directory name. The step
output, the log line, and the summary all said .skillscope-action, which is
the one place a caller looks to confirm the pin did what they meant.

It now reads __version__ out of the checkout it installs from:

[skillscope] 0.1.1 from /home/runner/work/repo/repo/.skillscope-action: uvx --from ...

Borrowed from #11's packaged_version(), which got this part right.

v0.1.0 is already tagged, and it is the broken one

#10 tells callers to pin @v0.1.0. That tag exists and every job inside its
reusable.yml says uses: amd/skillscope@main — so following those docs
reproduces the exact bug being fixed. Bumped to 0.1.1 and moved the documented
pins with it, and docs/usage.md now says why v0.1.1 is the first tag where
pinning does what the README claims.

This is a docs-and-packaging bump only. Nothing in the workflows names a
version, so the next release is a tag on whatever commit you like — no 21
literals to bump, which is the difference from #11.

Two tests, neither of them a ref check

• A selftest step asserts the version the action reported is the one in the
  checkout. It is the end-to-end statement that nothing fetched a build from
  somewhere else.
• TestTheVersionIsOneNumber keeps __version__ and pyproject.toml in
  agreement, and loads bootstrap/launch.py with runpy to check the
  launcher's scraping regex still matches the file it is aimed at. The launcher
  cannot import skillscope — it runs before anything is installed — so that
  regex is the one thing here that can rot silently.

Not borrowed from #11: the test that pins 21 literal uses: refs to
__version__. #10's derivation makes those literals disappear, so there is
nothing left to keep in agreement.

Worth knowing before merging #10

job.workflow_sha / job.workflow_repository are github.com only — not on
GitHub Enterprise Server. A GHES caller gets empty values, actions/checkout
falls back to their own repo, and uses: ./.skillscope-action fails to find
action.yml. That is a loud failure rather than a silently wrong harness, so I
think it is the right trade, but it is the one real argument for #11's literals
and it should be a deliberate call.

Also: the nested checkout uses the default GITHUB_TOKEN, which works because
amd/skillscope is public. If it ever goes private, that step needs a token.

Test plan

• python -m unittest discover -s tests -t . — 209 pass
• Ran the launcher end to end against this checkout: reports version=0.1.1,
  not .skillscope-action
• git grep v0.1.0 finds only the prose explaining why that tag is broken