…tings

`aube config set allowBuilds.@scope/pkg true` fell through to ~/.npmrc,
where aube doesn't read the dotted key and npm warns/errors about an
unknown user config. Surface an explicit error
(ERR_AUBE_CONFIG_NESTED_AUBE_KEY) pointing at the right edit site
(`aube approve-builds` for `allowBuilds`; workspace yaml /
`package.json#aube.<name>` for other maps) and leave .npmrc untouched.

Discussion #617 follow-up.

… writes to the npm-shared surface

Inverts the `aube config set` routing so `.npmrc` writes only happen for
keys that are part of the multi-tool npm contract — per-host auth/cert
templates (`//host/:_authToken`, `//host/:_password`, …), scoped
registries (`@scope:registry`), and a curated allowlist of npm-standard
scalars (`registry`, `email`, `proxy`/`https-proxy`, `cafile`,
`strict-ssl`, `init-author-*`, …).

Everything else now lands in aube's own config
(`~/.config/aube/config.toml` at user-scope, `<cwd>/.config/aube/config.toml`
at project-scope):

  - known aube/pnpm settings whose scalar value was previously routed there
  - `typedAccessorUnused = true` knobs like `dangerouslyAllowAllBuilds`
  - genuinely unknown free-form keys (new behavior, opt-in via direct
    `.npmrc` edits if a third-party tool needs to read them)

Aube map settings (`allowBuilds`, `overrides`, `packageExtensions`, …)
are rejected up front — they need structural edits in workspace yaml or
`package.json#aube.<name>`. `aube approve-builds <pkg>` is suggested in
the error help for `allowBuilds`.

`aube config delete` now sweeps both aube's config and `.npmrc`, so the
call works regardless of which file the value originated in (including
legacy writes from older aube versions).

Reading is unchanged — aube still reads `.npmrc` for compatibility.

Discussion #617 follow-up (broader take on iki's "are there still
non-npm settings going to `.npmrc`?" question).

`aube config set --local <map>.<entry> <value>` now edits one entry of
an aube map setting in place — same path `aube approve-builds` and
install-time auto-deny seeding take:

  aube config set --local allowBuilds.@mongodb-js/zstd true
  aube config set --local overrides.lodash 4.17.21

Writes land in `pnpm-workspace.yaml#<map>.<entry>` when a workspace yaml
exists, otherwise `package.json#<pnpm|aube>.<map>.<entry>` via the
existing `edit_setting_map` / `config_write_target` helpers. Bool /
integer / string values round-trip with their natural scalar type.

User-scope still errors (uniformly, no per-setting special case) because
aube only reads these maps per project today — the error points at
`--local` rather than dropping the value into `~/.config/aube/config.toml`
where nothing would read it.

Addresses greptile feedback on PR #634:
  - drops the hard-coded `meta.name == "allowBuilds"` branch (the
    project-scope path succeeds and the user-scope message is uniform
    across all map settings)
  - new tests cover both the `allowBuilds` and `overrides` paths at
    both scopes, plus a scalar-with-dot rejection (`autoInstallPeers.foo`)

aube-manifest gets a new `pub fn upsert_map_entry` that generalizes the
write-routing the existing allowBuilds path uses.

…rlap settings

Settings like `engineStrict`, `ignoreScripts`, `color`, `loglevel`,
`httpsProxy`, `maxsockets`, and `fetchRetries` are both:
  - in `is_npm_shared_key` (npm reads them from `.npmrc`)
  - known aube settings in settings.toml

Before this fix, an `aube config set engineStrict false` write would
land in `.npmrc` but leave any prior `config.toml` entry intact. Since
the resolver gives `userAubeConfig` higher precedence than `userNpmrc`
(matches the priority install uses), the stale `config.toml` value
silently shadowed the new `.npmrc` value — `aube config get` would
return the old value and the user's write would appear inert.

`write_npmrc` now sweeps the matching `config.toml` entries (canonical
name + every literal alias) on every `.npmrc` write that touches a
known aube setting. No-op for keys that aren't known aube settings
(auth tokens, scoped registries, npm-only scalars).

Spotted by cursor[bot] on PR #634.

`is_npm_shared_key` used `rest.contains(":registry")` which would
match `@scope:registry.foo` and `@scope:registryfoo` as if they were
scoped-registry templates and route them to `.npmrc`. The npm pattern
is exactly `@scope:registry` with nothing after — switch to
`ends_with(":registry")`.

Spotted by cursor[bot] on PR #634.

`scalar_to_yaml_json` had an integer branch that would serialize
pure-digit values as YAML / JSON numbers. That breaks aube map writes
like `overrides.express 4` (a valid "any 4.x" version spec) because
pnpm's (and aube's) typed-`String` deserializer rejects integer
values without a custom visitor. Only booleans get a typed
representation now — `allowBuilds` genuinely stores `true` / `false`,
but every other aube map value (override versions,
package-extension ranges, deprecated version specs, …) must
round-trip as a string.

Spotted by greptile-apps[bot] on PR #634.

…ings

`set --local allowBuilds.<pkg> true` writes to `pnpm-workspace.yaml`
(or `package.json#aube.allowBuilds.<pkg>` if no workspace yaml), but
the dotted form had no symmetric delete path. The fall-through error
said "not set in aube config or .npmrc" while the value sat stuck in
the workspace yaml.

Mirrors the existing `try_set_aube_map_entry` flow:
  - new `aube_manifest::workspace::remove_map_entry` helper that
    sweeps `<map>.<entry>` from both the workspace yaml (when present)
    and `<pnpm|aube>.<map>.<entry>` in `package.json`, scrubbing
    empty `<map>:` containers so deletes don't leave a `{}` stub
  - `try_delete_aube_map_entry` in `delete.rs` short-circuits the
    dotted form before the generic delete logic runs, with the same
    `--local` hint at user scope as `set`

Spotted by greptile-apps[bot] on PR #634.