FDR-0019: multi-dot (..name) — operate path ignores cwd-depth (drop the cwd-depth>0 reject)

[friedenberg]

Context

madder#153 landed (22b6c7a): MakeDefaultAndInitialize now resolves a multi-dot
id (..name) by walking up cwdDepth literal parent directories and errors on
overflow. dodder's genesis.go (init) and command_components_dodder/env_repo.go
(info-repo/serve) call that constructor, so multi-dot resolves correctly on
those paths once repo_id.EffectiveId preserves the depth
(scoped_id.EffectiveId(id).WithCwdDepth(id.GetCwdDepth())).

But the main operate path does not use that constructor. show/query/edit
build their repo via MakeLocalWorkingCopy
(command_components_dodder/local_working_copy.go), which resolves through
env_dir.MakeDefault(repo_id.EffectiveName(config.RepoId)) — a name string.
MakeDefault does a filesystem nearest-ancestor .dodder/ walk-up and never sees
cwdDepth (or the id's location). Confirmed by tracing
local_working_copy.Make → env_repo.Make on env_locals already resolved
name-only.

The problem

So if the cwd-depth>0 reject in repo_id.CheckSupported is dropped, ..work
would be accepted but the operate path resolves it to the nearest ancestor
named work, silently ignoring the depth — mis-resolving exactly the
multi-same-name-ancestor disambiguation case multi-dot exists for. That is a
regression from today's clear rejection, so the reject is kept for now (per
maintainer decision).

Required work (before dropping the cwd-depth>0 reject)

1. madder: expose a store-aware, depth-ranked cwd walk-up for the operate
   path. The discovery code already has one (FindAllCwdOverridePaths /
   makeAncestorOverrideStores, deepest-first, name-ranked), but it is not
   exposed for MakeLocalWorkingCopy's resolution. Note: the operate path must
   stay store-aware nearest-ancestor (so you can operate from a child dir) — it
   cannot just switch to MakeDefaultAndInitialize's literal walk-up, which would
   break operating from a workspace checkout below the .dodder/.
2. dodder: make local_working_copy.go honor cwdDepth for cwd ids via that
   resolver, and make repo_id.EffectiveId preserve cwdDepth (currently
   delegates to scoped_id.EffectiveId, which drops it).
3. Then drop the cwd-depth>0 reject in repo_id.CheckSupported and offer
   multi-dot in -repo_id completion.

Note

This revises the assumption in madder#153 that MakeDefaultAndInitialize is
dodder's operate path — it is the init/establish path; the operate path is a
separate name-only resolver. Coordinate with the madder owner before starting.

:clown: via clown 0.3.12+5220e30 — amarbel-llc/clown@5220e30

[friedenberg]

Madder-side surface (from the madder owner, for when this is greenlit — no action yet):

• FindAllCwdOverridePaths is already public (pkgs/directory_layout): the store-aware, ceiling-respecting, deepest-first ancestor walk.
• The depth-ranking (per-name cwdDepth tagging — "the Nth same-named ancestor store") currently lives in makeAncestorOverrideStores, which is internal to blob_stores (unexported).
• So the madder piece for this issue is likely: expose a depth-ranked resolution helper (cwd + name + depth -> the Nth same-named ancestor store) built on FindAllCwdOverridePaths, for MakeLocalWorkingCopy to consume — reusing the discovery logic rather than duplicating it.
• The operate path must stay store-aware nearest-ancestor (so you can run from a child dir) — it must NOT switch to MakeDefaultAndInitialize's literal walk-up (that's the init/establish semantics, remote_http: refactor Server to expose a KeySource interface for testability #153). This is the deliberate two-semantics split: literal for init, store-aware-depth-ranked for operate.

:clown: via clown 0.3.12+5220e30