FG3 build-out: six FG3-x sub-process packages + FG3-1 executable

Adds the six FG3 sub-process packages (processes/fg3-1 .. fg3-6) and wires
them into the FG3 (L2) package via `includes`; FG3 version 0.1.0 -> 0.2.0.

FG3-1 (Rēķina/kredītrēķina saņemšana par precēm/pakalpojumiem) is built out
as an executable L4 package:
- bpmn/rekina-sanemsana.bpmn  - 3-lane process (Nodarbinātais / VPC / Iestāde)
- dmn/rekina-parbaude.dmn     - FIRST hit-policy routing decision table
- resources/                 - roles, agent and mappings binding every user
                               task and the decision to a target
- metadata/                  - ownership, lifecycle, policies

FG3-2..FG3-6 are draft composition placeholders (L4) pending executable
build-out.

Validated against the UAPF 2.2.0 schemas (manifest, ownership, lifecycle,
policies, resource-mapping, enterprise index): all includes resolve, no
duplicated executable artifacts, BPMN/DMN well-formed, and all resource
mapping references resolve to real BPMN/DMN element ids.

processes/fg3-1/README.md

@@ -0,0 +1,64 @@
+# FG3-1 — Rēķina/kredītrēķina saņemšana par precēm/pakalpojumiem
+
+Level 4 atomic executable process for the receipt and processing of supplier
+invoices and credit invoices for goods and services — the FG3 demonstrator
+taken to executable depth.
+
+- **UAPF level:** L4 (atomic executable)
+- **Package id:** `vk.gramatvediba.fg3-1`
+- **Included by:** `processes/fg3` (function group FG3).
+- **Source:** Valsts Kase *Grāmatvedības uzskaites procesu apraksts* — FG3
+  schema and process register.
+
+## Process
+
+`bpmn/rekina-sanemsana.bpmn` (`Process_RekinaSanemsana`) transcribes the
+invoice-receipt flow across three lanes mapped from the source RACI columns:
+
+- **Nodarbinātais** — invoice arrives (e-invoice via e-address, or paper).
+- **VPC** — registration in the DVS, formal checking, contract/PO matching,
+  routing, posting and payment-order preparation; manual review where needed.
+- **Iestāde** — substantive approval by the responsible officer.
+
+Flow: register in DVS → formal check → match to contract/PO → routing
+decision → substantive approval → post → prepare payment order. Two
+terminating outcomes: *posted and queued for payment*, or *returned to the
+supplier*.
+
+## Decision
+
+`dmn/rekina-parbaude.dmn` (`Decision_RekinaMarsrutesana`) is a `FIRST`
+hit-policy decision table that sets the routing variable `marsruts` from three
+inputs:
+
+| Input | Values |
+|-------|--------|
+| `formalaParbaude` | `atbilst`, `neatbilst` |
+| `ligumaSasaiste` | `pilna`, `dalena`, `nav` |
+| `dokumentaTips` | `rekins`, `kreditrekins` |
+
+Outcomes: `return` (failed formal check), `manual-review` (no/partial contract
+match, or any credit invoice), `process` (formally valid, full match, plain
+invoice). The `Task_NoteiktMarsrutu` business-rule task evaluates it.
+
+## Resources
+
+`resources/mappings.yaml` binds every BPMN user task and the DMN decision to a
+target in `resources/roles.yaml` / `resources/agents.yaml`. Human steps are
+`manual`; the AI agent `agent.rekinu-asistents` is bound `assisted` to the
+formal check, contract matching and the routing decision — it suggests, the
+accountant decides. No step is `autonomous`.
+
+## Transcription note
+
+The process structure, lanes, systems and SLAs are transcribed from the
+published FG3-1 schema and register. Step identifiers here use stable BPMN/DMN
+element ids; reconciliation of these against the source register's `process
+nr.` numbering is a tracked follow-up and any schema/register discrepancy is
+to be recorded rather than silently resolved (see `docs/conventions.md`).
+
+## Status
+
+Draft. The package is structurally complete and validates against the UAPF
+2.2.0 schemas; lifecycle status advances to `review` once the source-numbering
+reconciliation is signed off.