fix(installer): ignore archive ownership on extraction

[xz-dev]

What does this PR do?

Prevents the Unix installer from preserving release-builder ownership when extracting verified tar archives.

The official v0.10.0 Linux portable archive records codebase-memory-mcp as runner/runner. When root extracts it with plain tar -xzf, GNU tar restores that foreign UID. Candidate staging then rejects the file because activation requires the source owner to match geteuid(), producing:

error: failed to stage install candidate: activation transaction I/O failed

Using tar --no-same-owner keeps extracted files owned by the invoking user and satisfies the existing activation security check. A smoke contract prevents the extraction flag from regressing.

Duplicate search found no issue or PR for this release-archive ownership root cause. Related but distinct reports: #1529 (Windows temporary-directory ACL) and #1483 (test fixtures under umask 002).

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Focused tests pass locally
• Focused lint/syntax checks pass locally
• New behavior is covered by a test (reproduce-first for bug fixes)

Verification:

• bash -n install.sh
• bash -n tests/test_smoke_fixture_contract.sh
• bash tests/test_smoke_fixture_contract.sh
• scripts/check-dco.sh HEAD^..HEAD
• git diff --check origin/main...HEAD
• Reproduced with a foreign-owner tar entry: plain extraction retained UID 12345; --no-same-owner produced current EUID.
• Verified official v0.10.0 archive records runner/runner; plain root extraction produced UID 1001 while patched extraction produced UID 0.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.