Setup repo: migrate architecture specs, code stubs, and tasks from alkhub_ts

Copy architecture docs, ADRs, storage domain specs, research, reviews,
and 56 storage architecture tasks from the alkhub_ts monorepo. Adapt for
standalone @alkdev/hub repo structure (src/ not packages/hub/).

Sanitize all sensitive information:
- Replace private IPs (10.0.0.1) with localhost defaults
- Remove internal server hostnames (dev1, ns528096)
- Replace /workspace/ private paths with npm package references
- Remove hardcoded credentials from examples
- Rewrite infrastructure.md without private network details

Add Deno project scaffolding: deno.json (pinned deps), .gitignore,
AGENTS.md, entry point. Migrate existing code stubs (crypto, config
types, logger) with updated import paths.

tasks/architecture/storage/enforce-parts-session-id-invariant.md

@@ -0,0 +1,38 @@
+---
+id: enforce-parts-session-id-invariant
+name: Document and enforce parts.sessionId denormalization invariant
+status: completed
+depends_on: []
+scope: narrow
+risk: high
+impact: component
+level: implementation
+---
+
+## Description
+
+The invariant stated in `sessions.md:96`: "when inserting a part, always set `sessionId` to the message's `sessionId`. Never update `messages.sessionId` without updating all child parts." However, there is no DB trigger, no CHECK constraint, no application-level transaction pattern, and no immutability guarantee for `sessionId`.
+
+The review recommends declaring `sessionId` on both `messages` and `parts` as **immutable after creation**, which eliminates the update problem. Define the application-level contract for part insertion and add an explicit "IMMUTABLE" note.
+
+## Acceptance Criteria
+
+- [ ] `sessions.md` documents that `sessionId` on both `messages` and `parts` is **IMMUTABLE after creation**
+- [ ] The column spec for `messages.sessionId` and `parts.sessionId` includes an IMMUTABLE annotation
+- [ ] The application-level contract for part insertion is documented: "read the message's `sessionId` and set it on the part within the same transaction"
+- [ ] The denormalization rationale is preserved but the invariant enforcement mechanism is explicit
+- [ ] Note added: "No DB trigger enforces this — immutability is respected by application layer; direct SQL must not update sessionId"
+
+## References
+
+- docs/reviews/storage-architecture-review-2026-04-21.md#C04
+- docs/architecture/storage/sessions.md:96
+- docs/architecture/storage/sessions.md:105
+
+## Notes
+
+> To be filled by implementation agent
+
+## Summary
+
+> To be filled on completion