Remove TODO.md; track open work in the issues (closes #76)

TODO.md is deleted and the README TODO section now only points to the
issue tracker, which is where open work and open design questions live
from now on. The section heading stays because the shared repo policy
requires it. AGENTS.md points at the tracker too.

Every open item in both lists was checked against the code and the
tracker: each was either already done or already owned by an issue,
apart from one, now filed as
#121. The 14 design questions are
all on #81,
#82,
#83 and
#79.

Model: opus-5-5

AGENTS.md

@@ -29,6 +29,4 @@ source for coding standards, formatting, linting, and workflow rules.
 - The format specification is in `FORMAT.md`.
 - Open work, open design questions included, is tracked only in the repo's
   issues: https://git.eeqj.de/sneak/mfer/issues. There is no `TODO.md` and no
-  TODO list in `README.md`; do not add either. For this repo this overrides the
-  `REPO_POLICIES.md` rule to put the todo list in the README, per sneak's
-  ruling: https://git.eeqj.de/sneak/mfer/issues/76#issuecomment-118130.
+  TODO list in `README.md`; do not add either.

README.md

@@ -157,23 +157,18 @@ The manifest file would do several important things:
     - metadata size should not be used as an excuse to sacrifice utility (such
       as providing checksums over each chunk of a large file)
 
-# Original Design Questions
-
-These were the open questions when the project started; open design questions
-are now tracked only in the [issues](https://git.eeqj.de/sneak/mfer/issues).
+# Open Questions
 
 - Should the manifest file include checksums of individual file chunks, or just
-  for the whole assembled file? If so, should the chunk size be fixed or
-  dynamic? Still open, on
-  [issue 81](https://git.eeqj.de/sneak/mfer/issues/81#issuecomment-118698).
+  for the whole assembled file?
+
+    - If so, should the chunksize be fixed or dynamic?
 
 - Should the manifest signature format be GnuPG signatures, or those from
   OpenBSD's signify (of which there is a good
-  [golang implementation](https://github.com/frankbraun/gosignify))? Still open,
-  as question 10 on [issue 82](https://git.eeqj.de/sneak/mfer/issues/82).
+  [golang implementation](https://github.com/frankbraun/gosignify)?
 
-- Should the on-disk serialization format be proto3 or json? Settled: it is
-  proto3, see `FORMAT.md` and `mfer/mf.proto`.
+- Should the on-disk serialization format be proto3 or json?
 
 # Tool Examples