fix(orb): registration-readiness and gittensor-config-recommendation routes are unreachable from a real browser session

[JSONbored]

⚠️ Definition of Done: this issue must be completed in full, in a single PR. Do not split this
work across multiple PRs, and do not defer any Deliverable below to a follow-up issue. A PR that
satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox
partially-done does NOT resolve this issue and will be closed.

Context

src/api/routes.ts:2705-2713 defines two route handlers, registration-readiness and
gittensor-config-recommendation, with no internal auth/role check at all — any authenticated
identity can call them for any repo. apps/loopover-ui/src/components/site/app-panels/owner-panel.tsx:49-60
calls both via useApiResource, which always sends credentials: "include"
(apps/loopover-ui/src/lib/api/use-api-resource.ts:52-55); the panel takes a free-text repo name
input rather than scoping to the caller's own repos, consistent with the intent of "any logged-in
user can look up any repo's readiness/recommendation."

Neither route has a matching predicate in canSessionAccessPath (src/api/routes.ts:6097-6124), so
a real non-operator browser session currently gets 403 on both, breaking the owner-panel's only two
data calls for every logged-in user who isn't using the internal operator bearer token.

This is the same root-cause class as the sibling issue filed alongside this one (three other routes
missing from the same allowlist) but is reported as a separate, smaller PR since these two routes
have no internal maintainer-check to compare against — i.e., it's slightly less certain this is "a
coded contract violated" versus "a product decision never wired up." It is, however, a confirmed,
reproducible break of a real UI panel's only two data calls.

Requirements

• Add matching predicates for registration-readiness and gittensor-config-recommendation to
  canSessionAccessPath, allowing any authenticated non-operator session to reach them (matching
  the routes' own current lack of an internal per-repo ownership check — do not add a new
  authorization restriction as part of this fix, only unblock the existing intended access).
• If, after reading the route handlers' full context, it becomes clear a per-repo restriction WAS
  intended and only the allowlist entry was forgotten (as opposed to intentionally open to any
  logged-in user), implement that restriction instead and say so explicitly in the PR description —
  do not leave this ambiguous.

Deliverables

• canSessionAccessPath allows a real (non-operator) authenticated browser session to reach
  registration-readiness.
• canSessionAccessPath allows the same for gittensor-config-recommendation.
• A new test in test/unit/access-boundary.test.ts, using its existing template, asserting a
  session-cookie-authenticated arbitrary logged-in user gets 200 (not 403) on both routes for an
  arbitrary repo name.
• The PR description states explicitly whether the fix simply unblocked the existing intended
  open access, or additionally added a restriction that was found to be missing.

All Deliverables above are required in the same PR.

Test Coverage Requirements

src/** is measured by codecov/patch (99%+ target, branch-counted). The new test(s) must exercise
both routes directly with a real session cookie (not a static bearer token), matching
access-boundary.test.ts's existing fixture pattern.

Expected Outcome

The owner-panel's registration-readiness and gittensor-config-recommendation data calls succeed
for any real logged-in user's browser session, matching the panel's own free-text-repo-name UX,
which presupposes open (not per-repo-restricted) access.

Links & Resources

• src/api/routes.ts:2705-2713 (the two route handlers), :6097-6124 (canSessionAccessPath)
• apps/loopover-ui/src/components/site/app-panels/owner-panel.tsx:49-60
• apps/loopover-ui/src/lib/api/use-api-resource.ts:52-55
• test/unit/access-boundary.test.ts (existing regression-test file and template)
• See the sibling issue filed alongside this one for the higher-confidence variant (3 routes with an
  internal maintainer-check but no matching allowlist entry)

[linear-code]

JSO-6004