Let a project inherit another repository's decisions at a pinned commit

[felipesauer]

What

A project can now inherit another repository's decisions, pinned to one commit.

• .mnema/inherit.json (committed) holds the origin (a git URL or a path) and a full commit hash.
• mnema inherit set <origin> [--at <revision>] and mnema inherit update [--to <revision>] print what would be inherited (for update, what changes between the current and the new commit) and write the pointer only with --write.
• mnema brief prints the inherited decisions in force in a section of their own that names the origin and the commit. They are read, never signed by the project, and the project's verify does not cover them.
• The record is verified at the pinned commit. One that does not verify, or that this machine cannot read, prints no decision, and the brief says which.
• Git is run through execFile with an argument array. The copy lives under the mnema home, outside the project tree. Only set, update, and a brief that finds its pinned commit missing touch the network; with no network and no copy the brief says so and the rest still prints.

Inheriting is trusting that repository at that commit; the help and the brief say only that.

Tests

• commands/inherit.test.ts: local origin repositories, no network. Covers plan without --write, the pointer file, the section, a record that does not verify, an unreachable origin with no copy, and update showing the change before moving the pointer.
• tests/a-project-inherits-a-record.test.ts: the same through the built binary, with the project's own record held byte-identical across set and update --write.
• Mutations: skipping the verification makes the tampered-record case fail; writing the pointer without --write makes the plan cases fail.

The surface's registries and goldens (verbs, completions, help page, censuses) are updated for the new verb. The guard on automatic git maintenance now exempts shipped modules, which call git with -c maintenance.auto=false themselves.