okf: recommend relative cross-links over absolute (§5.1/§5.2)

[jeromeetienne]

Fixes #157

Problem

SPEC §5.1 recommended /-prefixed absolute (bundle-relative) links, but
these only resolve correctly in an OKF-aware consumer. A raw renderer resolves
a leading / against its own root — the host origin in a browser, the repo
root on GitHub — which is not the bundle root once the bundle is nested as a
subdirectory within a larger repository (which §3 explicitly allows). In that
case the links mislink or 404, cutting against OKF's zero-tooling portability
goal.

The reference implementation had already voted against the spec on this:

• The agent prompt (reference_instruction.md) forbids leading /
  ("Never start a link with / (that breaks GitHub rendering)").
• Every cross-link in the shipped bundles/*/ concept files is relative.

So the spec recommended absolute → the agent forbade absolute → the bundles use
relative. The only thing out of step was the "recommended" label in the spec.

Change

Adopt resolution (1) from the issue — recommend relative links, keep absolute
as a supported OKF-aware-only form:

• Swap §5.1 / §5.2 so relative links are §5.1 and marked (recommended),
  with the rationale that they resolve in any standard renderer (cat, browser,
  GitHub, editor preview) without OKF tooling. Noted drawback: breaks if a
  document moves.
• Reframe absolute links as §5.2, documenting that they require an
  OKF-aware resolver and spelling out the browser/GitHub/nested-subdirectory
  failure mode.
• Update the §4.3 / §4.4 examples to use the now-recommended relative form
  so the spec's own examples model the guidance.

Spec-text only — no code changes; this aligns the spec with what the reference
agent and bundles already do.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jeromeetienne]

i signed the CLA

[SunsetDrifter]

+1. No objection to recommending relative links, but the new §5.2 wording is easy to read as "optional to implement", and that's already the reality: the reference visualizer silently skips leading-/ links, so a conformant bundle renders with zero edges and no warning (#48; open fixes in #66, #110, #184, #206). Please pair the swap with an explicit consumer requirement, e.g. "Consumers MUST resolve this form against the bundle root", so existing bundles that use absolute links keep working across tools.

[jeromeetienne]

Good catch, pushed jeromeetienne@f87f8d3 which adds an explicit MUST-level requirement for the absolute form (now §6.1):

Consumers that resolve cross-links MUST resolve an absolute link against the bundle root, not against their own root. A consumer MUST NOT silently drop or ignore an absolute link it cannot resolve. It MUST surface the unresolved link in the same way it surfaces a broken relative link.

That should close the "optional to implement" reading. The reference visualizer's silent-skip behavior itself is tracked separately in #48 (with fixes in #66, #110, #184, #206), this PR fixes the spec wording; those issues will bring the reference implementation into compliance with it.