fs-router 0.1.0 published peer-dep is stale (vue-router ^4.5.0 vs source ^5.0.6) — republish as 0.1.1

[Goosterhof]

Problem

Published @script-development/fs-router@0.1.0 declares a stale vue-router peer-dep range that no longer matches the source.

Verified discrepancy:

Location	peerDependencies.vue-router
Source packages/router/package.json	^5.0.6
Published 0.1.0 on npm	^4.5.0

$ npm view @script-development/fs-router peerDependencies
{ vue: '^3.5.0', 'vue-router': '^4.5.0' }

Source updated to vue-router 5 was not followed by a republish.

Cross-territory impact

Two consumer territories ship vue-router@^5.x and silence the resulting peer-dep complaint with .npmrc legacy-peer-deps=true:

• brick-inventory-orchestrator/frontend — vue-router: ^5.0.3, .npmrc legacy-peer-deps=true.
• ublgenie — currently development has .npmrc removed (PR #120), but PR #162 (UBL-0023 fs-packages domain wave) needs to reintroduce it to satisfy the same stale peer.

That's 2 of 3 fs-router consumers carrying the same workaround for the same upstream cause.

Proposed fix

Republish as @script-development/fs-router@0.1.1 so the npm-published peer matches the source declaration. No source-code change required — the source is already on ^5.0.6. After publication:

1. Bump consumer ranges (^0.1.0 → ^0.1.1) in BIO frontend + ublgenie (and any future consumers).
2. Drop .npmrc legacy-peer-deps=true from BIO frontend.
3. Drop the .npmrc reintroduction from ublgenie PR #162 before merge (or as a follow-up cleanup PR).

References

• War-room enforcement queue fs-packages M1 moderate remediation (Armorer) #33 (peer-range cascade) covers the recurring class.
• Consumer-side observation: ublgenie PR #162 review (https://github.com/Back-to-code/ublgenie-app/pull/162#review).
• BIO frontend: frontend/package.json + frontend/.npmrc.

Filed by the war-room General during the UBL-0023 ally PR review. Surfacing here because the right fix is upstream, not per-territory reverts.