* test: reproduce startup deletion of tracked skill links

* fix: retire legacy startup skill reconciliation for PRD-8690

* docs: disclose retired startup skill repairs and annotate stale specs for PRD-8690

Name the removed startup repairs in the release note, add post-ship
corrigenda to specs that still present skill-reconcile as live, drop
dead filenames from the server README, and isolate the boot ownership
test from ambient git config.

* docs: complete the PRD-8690 corrigendum sweep and scope the release remedy

Annotate the remaining claims that still present the deleted reconcile
pass as live in the specs this branch touches, move the roadmap
breadcrumb into the cell holding the claim it corrects, and name
reinstall as the remedy for a link the retired repairs used to heal.

* docs: annotate the two specs outside the branch diff that still cite the reconcile module

The sweep so far covered only the specs this branch already edited. The
skill-management opt-in spec still described reconcileSkillInstalls as
running on project open and listed skill-reconcile.ts under current-tree
affected code, and the cross-harness enumerator spec still listed that
module as verified substrate to reuse. Both are falsified by the
deletion, so both get the same post-ship breadcrumbs.

* docs: annotate FR7 and scope the release remedy to the path that performs it

FR7 asserted that existing copy-installs are auto-converted to symlinks
on open. The replace branch went with skill-reconcile.ts and the
surviving startup step creates no symlinks, so the row gets the same
breadcrumb its neighbours carry.

The remedy clause claimed reinstalling converts a copy. That is only
true where the destination is absent or a link. On the in-place path a
same-copy destination converts only under an explicit link-mode
install, so the clause now names that action for the copy case and
keeps reinstall for the link cases.

* docs: annotate the projection-timing claim in the explore-discovery spec

The sweep so far covered the docs this branch already touched plus the
two found by a repo-wide grep. A third one was still presenting the
retired module as live: the explore-discovery spec's projection-timing
bullet is marked verified and names the on-open reconcileSkillInstalls
as one of the two paths that project a .ok skill, concluding that an
imported skill reaches the editors on the next reconcile or open.

boot.ts now runs only migrateStoreSkillsInPlace, so there is no on-open
reconcile and an explicit install is the only projection path left. The
bullet gets the same same-line breadcrumb its neighbours carry.

The two remaining untouched references are SCOPE lines in unshipped
plans (agent-skill-authoring-ux and ok-prd6935-audit-remediation), which
state what a plan intends to touch rather than what the tree does. They
stay in the forward-looking class this sweep has excluded throughout.

* docs: finish the sweep inside both newly annotated specs and fix the release remedy

The last two specs to enter the corrigendum population carried
uncorrected occurrences beside the corrected ones, because the
enumeration searched for the module and symbol names and those sites
say "reconcile" bare or name a symbol the module defined.

In the opt-in spec, D2's always-on list, the whole D3 path table and
the sameSkillModuloFrontmatter compare it cites, and both reconcile
bullets in the test plan now carry the same breadcrumb the rest of the
doc does. In the enumerator spec, slice 5's reconcile forked-state row
gets the annotation its identical sibling in the roadmap already had.

The release note's remedy clause sent the copy case to manual handling
alongside duplicates, though the install menu converts a copy to a
symlink directly. The clause now names that action, which also makes it
match what the PR body and the disposition record describe. 46 words
under the guard's count.

* docs: annotate the three remaining explore-discovery sites and one spec the sweep had not reached

The explore-discovery spec entered the corrigendum population one
commit ago and got a breadcrumb at the single site the enumeration
found. Scanning that file for the bare "reconcile" form returns four
lines, not one. The toggle-gating bullet, the import bullet that
restates it, and the D13 decision row all assert the premise the new
breadcrumb retracts, and D13 is the sharpest: its stated motivation is
a deferral fallback that no longer exists, so an implementer reads an
unprojected import as eventually projecting on the next open when it
never projects until an explicit install runs.

Widening the same scan across the subtree turned up a spec no round had
looked at, agent-skill-authoring-ux, which is marked Implemented and
describes A2 as a reconcile-time heal. Checked first whether this
branch had deleted that behavior: it had not. The deleted module
carries no name-versus-folder heal at all, and the enforcement lives in
the write path, returning NAME_DIR_MISMATCH. Only the documented
trigger is now false, so the item summary, the What line and the
acceptance line carry breadcrumbs.

Two classes stay excluded and are now named on the record in the
disposition: dated document-header provenance lines, and session SCOPE
constraint lists.

* docs: correct the projection-timing breadcrumbs to the import route that shipped

The breadcrumbs added at the projection-timing bullet and the D13 row
paired a correct retraction with a wrong one. Deleting
reconcileSkillInstalls does remove the on-open reconcile, but it does
not leave an imported skill unprojected: handleSkillImport passes
skipProjection: body.install === false and install defaults to true, so
runSkillImport resolves editor targets and calls projectInPlaceSkill at
import time. D13's substance shipped, which is the opposite of what a
reader scoping follow-up work would have taken from a LOCKED row whose
only current-tree claim said the requirement was now more urgent.

The residual is narrower and worth naming, because nothing heals it on
the next open any more: resolveSkillTargets falls through to project
detection when the caller names no editors, the fan-out only runs under
targets.length > 0, and its catch logs "post-import editor fan-out
failed (import kept)" and keeps the import. A project with no detected
editor, and an import whose fan-out throws, both land managed and
unprojected. Both breadcrumbs now say that instead.

The shipped prose on both lines is untouched per the corrigendum
convention, so the bullet's gap-to-close framing and D13's LOCKED
status stand and the breadcrumbs are what record that it shipped.

* docs: stop the projection-timing breadcrumbs asserting a closed residual

Both breadcrumbs named two unprojected cases and closed the list. There
is a third, and it is the one this PR's retirement bears on:
projectInPlaceSkill's per-target switch sends a destination that
classifies as different to conflicted and materializes nothing, with the
stale-bundle escape gated on internal bundle names. A project whose one
detected target already holds a different same-named skill therefore
ends the import unprojected with a non-empty target list and nothing
thrown, so neither named condition covered it.

It is also the quietest of the three. runSkillImport calls
projectInPlaceSkill without binding its hosts/conflicted return, and the
import response's warningCodes is the authoring code list, whose two
members are skill-name-vendor-word and skill-body-too-long, so the
conflict produces no log line and has no field to travel in. The install
path turns the same array into a name-conflict warning with display
text.

Both lines now drop the "the only" and "what remains" framing and name
the third case, rather than swapping one exhaustive list for another.
The quoted log string, the on-open reconcile retraction, the
inline-projection claim and the same-line placement are unchanged, the
shipped prose is untouched, and the D13 row is still four cells.

GitOrigin-RevId: e3a33c2d0442defa764249b0dddcfcc8ad0cccc9