Add project registration endpoint

docs/project-registration-policy.md

@@ -64,15 +64,23 @@ These map to the configured Dalidou source boundaries.
 For a new project:
 
 1. stage the initial source docs on Dalidou
-2. add the project entry to the registry
-3. verify the entry with:
+2. inspect the expected shape with:
+   - `GET /projects/template`
+   - or `atocore.sh project-template`
+3. preview the entry without mutating state:
+   - `POST /projects/proposal`
+   - or `atocore.sh propose-project ...`
+4. register the approved entry:
+   - `POST /projects/register`
+   - or `atocore.sh register-project ...`
+5. verify the entry with:
    - `GET /projects`
    - or the T420 helper `atocore.sh projects`
-4. refresh it with:
+6. refresh it with:
    - `POST /projects/{id}/refresh`
    - or `atocore.sh refresh-project <id>`
-5. verify retrieval and context quality
-6. only later promote stable facts into Trusted Project State
+7. verify retrieval and context quality
+8. only later promote stable facts into Trusted Project State
 
 ## What Not To Do
 
@@ -93,3 +101,9 @@ Use:
 And the API template endpoint:
 
 - `GET /projects/template`
+
+Other lifecycle endpoints:
+
+- `POST /projects/proposal`
+- `POST /projects/register`
+- `POST /projects/{id}/refresh`

docs/source-refresh-model.md

@@ -85,6 +85,8 @@ The first concrete foundation for this now exists in AtoCore:
 - a project registry file records known project ids, aliases, and ingest roots
 - the API can list those registered projects
 - the API can return a registration template for new projects
+- the API can preview a proposed registration before writing it
+- the API can persist an approved registration to the registry
 - the API can refresh a single registered project from its configured roots
 
 This is not full source automation yet, but it gives the refresh model a real