docs: update the site for happ-0.5.0-beta.1

[Soushi888]

SoushAI analysis. Drafted by Soushi's AI assistant, reviewed and posted by @Soushi888.

Stacked on #8. That PR makes main the branch that publishes; this one fixes what the pages say. Review and merge #8 first, and this diff will then be against main.

What was wrong

The live site describes hREA v0.3.3 on Holochain 0.5.x, hands out the happ-0.3.3-beta DNA, and pins the adapter at 0.0.4-alpha.4. The published release is happ-0.5.0-beta.1: Holochain 0.7, @holochain/client ^0.21.0, ValueFlows 1.0.

Beyond the version strings, the flagship code example does not run. The adapter takes { appWebSocket, roleName } and is synchronous; the page shows await createHolochainSchema({ holochainClient, dnaRoleName }).

Guides

• Quick Start retargeted. The scaffold step now uses holonix?ref=main-0.7, which is what hREA's own flake.nix tracks. This matters: the official get-started guide still pins main-0.6 at the time of writing, and a 0.6 app cannot load this DNA.
• Integration Guide rewritten. Both published artifacts are named with the case each one serves, the DNA URL points at happ-0.5.0-beta.1, and the dependency block carries @holochain/client ^0.21.0 and @valueflows/vf-graphql-holochain ^0.700.0-rc.0. There is an explicit note for the state the registry is in right now: if npm view still shows 0.600.0-rc.0 as latest, the 0.7 adapter has not been published yet, and the fallback is a source build. See ci(adapter): publish @valueflows/vf-graphql-holochain from CI hREA#418.
• Basic Usage rewritten around the real API, with the query, the mutation, and the offers and requests partition. The connection wiring follows clients/acceptance/src/harness.ts in the hREA repository rather than being invented here.
• Consuming a release, new. What to pin, artifact choice, and the upgrade hazard that matters most: happ-0.4.0-beta shipped stub validators, this release enforces the rules, so writes the old conductor accepted can now be rejected. It links the hREA repository's own document rather than copying it.
• Enabled Modules replaces a page that said "Coming soon..." with the sixteen modules that are enabled and the fact that the set is fixed at build time.
• Using myAgent kept at its address, rewritten. myAgent is declared in the schema and has no resolver; associateMyAgent is not in the schema at all. The page now says so and gives the pattern that works.

Reference

Reconciled against the schema the adapter actually builds. The schema was printed with printSchema(createHolochainSchema({ appWebSocket: null, roleName: 'hrea', cell })), the same no-conductor path scripts/verify-purpose-schema.mjs uses, so the edits are against the real SDL rather than transcribed from release notes.

Removed, because the types are not in the schema and an operation naming them fails at validation: Appreciation, Scenario, Geolocation. Their ValueFlows modules are not enabled. Geolocation's replacement is SpatialThing.

Settlement removed as a type. There is no Settlement, no settlements query and no createSettlement in the schema. Settlement is EconomicEvent.settles, with Claim.settledBy as the reverse. The old Claim page documented an API that does not exist.

Added: SpatialThing, AgreementBundle.

Fields added where they were missing: Proposal.purpose with the ProposalPurpose enum, ResourceSpecification.mediumOfExchange, EconomicEvent.settles, EconomicEvent.reciprocalRealizationOf, Commitment.reciprocalClauseOf.

Marked, not deleted: AgentRelationship, AgentRelationshipRole and myAgent are declared in the schema with no resolver. ProductBatch is a type with no operations at all. The reference index now carries a three-state table, so someone planning an integration can see at a glance what will actually answer.

The index also states the two CRUD asymmetries that catch people: no deleteEconomicEvent, and no createEconomicResource or deleteEconomicResource, since a resource comes into being through newInventoriedResource on createEconomicEvent.

Verification

• mkdocs build --strict passes. The same check was confirmed able to fail, on a deliberately broken nav entry, before being relied on.
• The built site was served locally: /, /integration-guide/ and /reference/graphql-api-reference/ all return 200.
• The build output was swept for stale strings. No hREA v0.3.3, no Holochain v0.5, no 0.0.4-alpha. The remaining occurrences of happ-0.3, dnaRoleName and associateMyAgent are all in the deliberate notes about what changed.
• Every schema claim traces to the printed SDL, not to prose.

Not verified: the rendered appearance. The browser I use for visual checks disconnected partway through, so nobody has looked at these pages in a browser. The structure is there in the HTML (admonitions render as class="admonition", code blocks are present), but if the theme does something ugly with the new callouts, this review is where it should be caught.

Follow-up, deliberately not in this PR

The reference is still hand-maintained, which is what let it drift into documenting a Settlement type that does not exist. The schema can be printed without a conductor, so it can be generated. That is a bigger change and belongs in its own PR.

[Soushi888]

SoushAI analysis. Drafted by Soushi's AI assistant, reviewed and posted by @Soushi888.

Correction to this PR's own description, pushed in 63ab22c.

The description and the original consuming-a-release.md both said that happ-0.4.0-beta shipped stub validators and that happ-0.5.0-beta.1 would reject writes the old conductor accepted. That is not true. The entity validators are byte for byte identical at the two tags, and the only change to the integrity zome between them is the Holochain 0.6 to 0.7 signature port, EntryCreationAction becoming TypedAction<EntryCreationData>:

git diff happ-0.4.0-beta happ-0.5.0-beta.1 -- dnas/hrea/zomes/integrity/

contains no semantic change. validate_intent_fields and validate_spatial_thing_fields, checked line by line at both tags, are the same. A write a 0.4.0 conductor accepted is still accepted.

What actually breaks on that upgrade is the platform: the conductor, @holochain/client, the adapter signature, and your own integrity zomes if you compose hREA alongside them. The section now says that instead.

The rules themselves were undocumented on the site either way, so this also adds docs/validation-rules.md: seven rule classes with their exact rejection messages and the entities each applies to, the 21-identifier action vocabulary, and the two entity-specific rules (WGS84 bounds on SpatialThing, minimumQuantity against availableQuantity on Intent). All of it read out of dnas/hrea/zomes/integrity/hrea/.

mkdocs build --strict exits 0 with the new page in nav.