release 0.5.0b6 (#470)

## Bump
- [ ] Major
- [ ] Minor
- [x] Beta
- [ ] Patch
- [ ] Skip

## Changelog

### Fixed
- Loading a Data Product binds each view to the RuleSet whose focus target class is that view. A neighbour stub in another view's rules no longer attaches that RuleSet to the neighbour view. Skipped stubs are shapes whose name ends in ExistenceShape, sh:node shapes with no constraints of their own, and a bare target-class shape when another shape in the same rules already has constraints. A SPARQL check on those stubs does not count as a focus class. A SPARQL target on a real focus shape still binds that view.
- When more than one RuleSet still matches a view, validation records take ruleSetId and ruleSetVersion from the RuleSet whose focus classes are exactly that view. The order of entries in quality.rules no longer chooses the stamp.

### Added
- Usage guide for building an app on the data quality engine: publishing Data Products and RuleSets (sibling bindings, version caps, a broken binding, and one historic run per publish) and querying immutable validation records (a lastUpdatedTime range on every filter and aggregate, cursor pages, and scores for the rules listed on screen).

### Changed
- Records, lifecycle, and Data Product editing guides state that ruleSetId is the primary focus RuleSet for the view, and that an immutable record query sends lastUpdatedTime on every filter, aggregate, and cursor page.
- Redeploy the validation function, then run Data Product sync or deploy, so each view's ruleset binding and new records use the focus RuleSet.
