Checkpoint 1: implement native subsystems and begin the gameplay manual

docs/manual/scripting/index.md

@@ -0,0 +1,41 @@
+# C++ gameplay
+
+In the first version of Faset, a "script" is C++ gameplay code compiled into your game.
+It is not an interpreted text file. The gameplay library is statically linked into
+a separate Player executable.
+
+The intended iteration cycle is:
+
+1. Stop Play.
+2. Edit your C++ behavior or system.
+3. Build the changed code and export its property schema.
+4. Start a new Player session.
+
+The Editor reads a schema generated by a separate SchemaExporter. It does not load
+your gameplay library into its own process. A gameplay crash therefore does not
+automatically crash the Editor. Editor native extensions have a different lifecycle
+and run inside the Editor process.
+
+!!! note "API examples are added with implementation"
+    This page describes the accepted execution model. Exact function signatures and
+    complete examples will be documented alongside compiling runtime examples, rather
+    than presenting proposed APIs as available functions.
+
+## Behaviors and systems
+
+A behavior gives an individual object lifecycle callbacks. A system operates on a
+set of objects with matching components. Both use the same runtime state; the visual
+scene and Inspector are the authoring view of that state.
+
+Persistent scene IDs and runtime handles are different. A scene ID survives saving
+and reopening. A runtime handle belongs to a particular world/session and can become
+invalid after an object is removed. Do not store raw component pointers across
+structural changes or treat a runtime handle as a save-file ID.
+
+## Physics ownership
+
+Physics owns the position of a dynamic rigid body. Move it with the supported physics
+commands instead of writing its presentation transform. A camera or other visual-only
+object can follow the interpolated result without modifying the simulation.
+
+Continue with [Frame and physics updates](lifecycle.md).